<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"><title>Saul Howard - hacking</title><link href="https://saulhoward.com/" rel="alternate"/><link href="https://saulhoward.com/feeds/hacking.atom.xml" rel="self"/><id>https://saulhoward.com/</id><updated>2023-08-31T00:00:00+01:00</updated><entry><title>Service politics</title><link href="https://saulhoward.com/service-politics" rel="alternate"/><published>2023-08-31T00:00:00+01:00</published><updated>2023-08-31T00:00:00+01:00</updated><author><name>Saul Howard</name></author><id>tag:saulhoward.com,2023-08-31:/service-politics</id><summary type="html">&lt;p&gt;Microservice architectures are a solution to scaling systems. Startups who start with a micro service architecture before they have scaling problems, sometimes before they even launch, attract ridicule.&lt;/p&gt;
&lt;p&gt;But microservices are also a solution to an engineering management problem. Startup codebases are usually a mess. Proof of concepts, abandoned features …&lt;/p&gt;</summary><content type="html">&lt;p&gt;Microservice architectures are a solution to scaling systems. Startups who start with a micro service architecture before they have scaling problems, sometimes before they even launch, attract ridicule.&lt;/p&gt;
&lt;p&gt;But microservices are also a solution to an engineering management problem. Startup codebases are usually a mess. Proof of concepts, abandoned features, quick hacks are what it takes to find the product.&lt;/p&gt;
&lt;p&gt;Developers keep returning to service architectures because the separation of concerns enforced by the network makes it easier to maintain the codebase, onboard new developers and adopt and abandon features. Maybe your startup has a loyal team of focused developers, and you can do all of that within a monolith. But many don’t. In &lt;a href="https://gist.github.com/chitchcock/1281611"&gt;Yegge’s Platform Rant&lt;/a&gt;, he showed how service contracts are necessary for managing multiple engineering teams, but individual developers can benefit from them too.&lt;/p&gt;
&lt;p&gt;Serverless functions, LLM-scaffolding, cloud IDEs and bounties for features are all on the rise. Increasingly, systems are built from loose federations of distributed functionality. Like all engineering solutions, it’s a tradeoff. Abstracting problems at the network layer gives you network problems. But it can solve for spaghetti-monoliths.&lt;/p&gt;</content><category term="hacking"/><category term="spaghetti"/><category term="knife-fights"/></entry><entry><title>Where’s the web 2023</title><link href="https://saulhoward.com/web-development-2023" rel="alternate"/><published>2023-08-26T00:00:00+01:00</published><updated>2023-08-26T00:00:00+01:00</updated><author><name>Saul Howard</name></author><id>tag:saulhoward.com,2023-08-26:/web-development-2023</id><summary type="html">&lt;p&gt;I tried out a few web frameworks and libraries recently. My thoughts:&lt;/p&gt;
&lt;h4&gt;Vite&lt;/h4&gt;
&lt;p&gt;I needed to upgrade some old React apps. It turned out they killed &lt;code&gt;create-react-app&lt;/code&gt;, and it seems like Vite is the go-to “just a React app” framework.&lt;/p&gt;
&lt;p&gt;Vite made the refactor painless. I think the only incompatible …&lt;/p&gt;</summary><content type="html">&lt;p&gt;I tried out a few web frameworks and libraries recently. My thoughts:&lt;/p&gt;
&lt;h4&gt;Vite&lt;/h4&gt;
&lt;p&gt;I needed to upgrade some old React apps. It turned out they killed &lt;code&gt;create-react-app&lt;/code&gt;, and it seems like Vite is the go-to “just a React app” framework.&lt;/p&gt;
&lt;p&gt;Vite made the refactor painless. I think the only incompatible thing was a new format for env vars. Other than that, it kept out of the way. Recommended.&lt;/p&gt;
&lt;h4&gt;Remix&lt;/h4&gt;
&lt;p&gt;I wanted a new app that would deploy to Cloudflare Pages/Workers. The worker runs an edge endpoint proxying to a GCP Python service for the heavy lifting.&lt;/p&gt;
&lt;p&gt;Remix was impressive. It has a nice balance of web fundamentals and React. I’m not so sure about the push away from React with tech like &lt;code&gt;htmx&lt;/code&gt;. I like React! I see their point — React apps are in some ways ephemeral, it’s diverging from the web and the ecosystem is chaotic. But for quick development in the real world, it works. I’d choose Remix over NextJS. Remix feels lighter, with less custom magic.&lt;/p&gt;
&lt;h4&gt;Astro&lt;/h4&gt;
&lt;p&gt;This one was cool. Astro has a great set of features for a static site generator that you can integrate into the rest of your stack with MDX and React, while keeping all the posts in Markdown.&lt;/p&gt;
&lt;p&gt;I could share React components from the main webapp for the layout and added endpoints to the Astro app to serve the Markdown content to the other services.&lt;/p&gt;
&lt;h4&gt;Bun&lt;/h4&gt;
&lt;p&gt;I want to love Bun. JavaScript/TypeScript/NodeJS is a mess, and one of these attempts to replace the toolchain in one blow has to work.&lt;/p&gt;
&lt;p&gt;I found myself writing a NodeJS service, so I set it up with Bun, and it was great — until I tried to pull in the SDK libs I needed to use. It turns out the NodeJS compatibility isn’t there yet.&lt;/p&gt;
&lt;p&gt;Usually the only time I’m writing NodeJS is because of a specific library I want to use. Bun is great for writing dependency-free services, but if the service is dependency-free why would I use TypeScript? I understand they are aiming for 100% compatibility, and I hope they get there.&lt;/p&gt;</content><category term="hacking"/><category term="spaghetti"/></entry></feed>