What is Wave?
In defense of simple architectures
71–80 of 196 posts
Re: In defense of simple architectures
#72There are some web apps still in production that I wrote almost a decade ago in Node+Express in the simplest, dumbest style imaginable. The only dependencies are Express and some third-party API connectors. The database is an append-only file of JSON objects separated by newlines. When the app restarts, it reads the file and rebuilds its memory image. All data is in RAM. I figured these toys would be replaced pretty…
Built-in first-class concurrency (ala node, golang, rust, etc.) is a huge win for simple architectures, since it lets you avoid adding a background queue, or at least delay it for a very long time.
I think people are also too quick to add secondary data stores and caches. If you can do everything with a transactional SQL database + app process memory instead, that is generally going to save you tons of trouble on ops, consistency, and versioning issues, and it can perform about as well with the right table design and indexes.
For example: instead of memcache/redis, set aside ~100 MB of memory in your app process for an LRU cache. When an object is requested, hit the DB with an indexed query for just the 'updatedAt' timestamp (should be a sub-10ms query). If it hasn't been modified, return the cached object from memory, otherwise fetch the full object from the DB and update the local cache. For bonus points, send an internal invalidation request to any other app instances you have running when an object gets updated. Now you have a fast, scalable, consistent, distributed cache with minimal ops complexity. It's also quite economical, since the RAM it uses is likely already over-provisioned.
This is exactly the approach that EnvKey v2[1] is using, and it's a huge breath of fresh air compared to our previous architecture. Just MySQL, Node/TypeScript, and eventually consistent replication to S3 for failover. We also moved to Fargate from EKS (AWS kubernetes product), and that's been a lot simpler to manage as well.
Re: In defense of simple architectures
#73What's the year on this? anybody know? Normally I check the Internet Archive, but https://web.archive.org/web/*/https://danluu.com/simple-arch... .
Based on Dan's Twitter, March 2022: https://twitter.com/danluu/status/1501644166983421953
That links to the original on wave.com, dated March 9th this year.
Re: In defense of simple architectures
#74How far can you get with a single Postgres instance on a single machine? I know things like cockroach and citus existence but generally Postgres isn’t sharded as far as I know.
Pretty far!
Re: In defense of simple architectures
#75What's the year on this? anybody know? Normally I check the Internet Archive, but https://web.archive.org/web/*/https://danluu.com/simple-arch... .
The "previous" article at the bottom is the most recent article in his archive, which was apparently published in March 2022. So I'm guessing this year, and either this month or last month. But the archive doesn't seem to have been updated yet with this article.
Ah ok - it's new then. Thanks to both of you!
Re: In defense of simple architectures
#76Earlier quoted context omitted.
I'd never worked with micro-services before this latest freelance project. I start working with this platform that is basically "note taking but with a bit of AI/ML". So okay, a bit of complexity with the ML stuff, but otherwise a standard CRUD app. The application itself is a total of 3 pages, encompassing maybe 20 endpoints at the most, with about 100 daily active users. For the backend, some genius decided to buil…
> 3 pages .... 74 unique services Just, wat. Sounds like the architect was doing some resume driven development cause damn.
In all honesty I'm very angry about it. It was built a while ago, and the dev is no longer here, but I almost want to track him down and make him help fix it. This founder isn't technical, so he's been leaning on developers for guidance, and this guy basically built him a skyscraper when what he really needed was a shed. It hurts to think about all the time and money that he's poured into just maintaining it. Crazy.
Re: In defense of simple architectures
#77At the risk of making an ad-hominem attack, I found this website unreadable. Minimalism is fine. But there comes a point when there's so little, it is nothing. danluu.com is a bucket of sand facing an overbuilt cathedral.
You can read the same content here: https://www.wave.com/en/blog/simple-architecture/
Re: In defense of simple architectures
#78At the risk of making an ad-hominem attack, I found this website unreadable. Minimalism is fine. But there comes a point when there's so little, it is nothing. danluu.com is a bucket of sand facing an overbuilt cathedral.
I set a user style in Stylus for danluu.com:
body { font: 16px/1.6em sans-serif; max-width: 50em; margin: auto; }
Re: In defense of simple architectures
#79How far can you get with a single Postgres instance on a single machine? I know things like cockroach and citus existence but generally Postgres isn’t sharded as far as I know.
Pretty far!
How far was exactly? Like tps for reads and writes with what specs?
I’ve been looking for real world performance.
Re: In defense of simple architectures
#80Earlier quoted context omitted.
Trap or integrated win-win? We use one of these "aggressively simple" architectures too. At this point, I would quit my job instantaneously if I had to even look at k8s or whatever the cool kids are using these days.
Man, kubernetes is so much easier than the smattering of crap that you have to jungle together before it. Puppet and co? No thanks. Terraform? It's fine, but only a part of a CI/CD picture. If you think the alternatives are better, I really have to wonder how much of the trenches crap that people in your org deal with regularly that you're insulated from. That, or you're a release-quarterly kinda company?
We wrote our own tools for most things. Our build is a single dotnet publish command, followed by copying the output to an S3 bucket for final consumption.
That output is 100% of what you need to run our entire product stack on a blank vm.
Monolithic pays for itself in so many ways. Sqlite and other in-process database solutions are a major factor in our strategy.