41–50 of 447 posts
Writes simple and then drops GraphQL and K8s.
you can absolutely use Kubernetes to implement a dead-simple three tier with minimal ops overhead, especially if you're using a managed cluster
Show me your problem, I'll show you how to solve it with the least amount of code and dependencies.
I'd argue that this article could be read more like "start as a monolith, and then move towards microservices when sensible", except the penny hasn't fully dropped for the author that the sensible time for their organisation is right now. The company appears dogmatically locked into their idling python code, their SQL making unpredictable commits, and their SQL framework making it difficult to make schema migrations.…
In what way does "moving towards microservices" relate to solving "data-integrity bugs"? I would argue the opposite - the more distributed you make the system, the more subtle consistency bugs tend to creep in.
I'm going to agree with Dan Luu by asking where I can find more of these sane companies. I want to spend an honest 6h a working day improving a product (Terraform and Webpack are not the product) and spend the rest of my time tending to my garden.
I agree with the general sentiment that simple architectures are better and monoliths are mostly fine. But. I've dealt with way too many teams whose shit is falling over due to synchronous IO even at laughably low volumes. Don't do that if you can avoid it. "Subtle data-integrity bugs" are not something we should be discussing in a system of financial record. Avoiding them should have been designed in from the start.
> Our architecture is so simple I’m not even going to bother with an architectural diagram. Instead, I’ll discuss a few boring things we do that help us keep things boring. Maybe that is why everyone goes with the the latest and greatest sophisticated techniques that are popular on the conference circuit. At least it has a diagram.
Our stack is a NestJS server, Handlebars templates for SSR, htmx and a PostgresSQL database. Deployed as a container on GCP Cloud run with a Github action. It's delightful to work on and very responsive in a way that a React app with the same data load wouldn't be. At this point it would take a pretty massive reason to get me to adopt the SPA approach again.
I usually also use Cloud Run for running my containers. But I use Cloud Build instead of GH Actions. I'm curious, what's your reasoning? I prefer my repository to just hold code and run build actions close to where it's deployed.
It's just a shame that the syntax will forever be a barrier to widespread adoption.
I suspect the era of VC-money and ZIRP led to a large number of engineers who were disconnected from successful long-term business outcomes, so there was no incentive to simplify.
The rest of the article goes into why the above is not the case.
The language was chosen because it was the CTO's pet, not for simplicity's sake. It wasn't the right choice: "its concurrency support, performance, and extensive dynamism make us question whether it’s the right choice for a large-scale backend codebase"
Synchronous/blocking wasn't chosen for simplicity's sake - the async libraries were buggy! To work around the performance issue:
1) a "custom protocol that runs on top of UDP" was written. No thanks.
2) putting work onto a queue. Event-sourcing, anyone?
> we’re having to split our backend and deploy on-prem to comply with local data residency laws and regulations
It's good that the software was a monolith, otherwise it would have been difficult to split apart /s.
Software is incidental complexity and essential complexity. If you shun certain things as 'too complicated', but they end up being in the essential complexity bucket, you're just going to be building them yourself, slower and with more bugs.
Imagine how different the article would have been had they picked technology whose concurrency, performance and typing worked in their favour.
Early in my career one of the IT guys told me that one of the people on staff was "a technical magpie". I looked at him with a raised eyebrow and he said "He has to grab every shiny piece of tech that shows up and add it to the pile". This is where we are. I can't tell you how many times I have seen projects get done just to pad a PM or developers resume. Just because it was the lastest and greatest hot shit thing to…