There 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…
In defense of simple architectures
191–196 of 196 posts
Re: In defense of simple architectures
#192Earlier quoted context omitted.
> 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
#193Earlier quoted context omitted.
Some people don't even realise how much traffic a simple web app with server side rendering (decently written), hosted on an average dedicated server can hold... They dont need cloud, autoscaling, microservices, kafka, event driven architectures, etc. We've lost our way in the masked marketing the cloud providers are creating to help us solve problems we will never encounter, unless we are building the next Netflix o…
If you want to get an idea of where things are at right now, this is a good place to start looking: https://www.techempower.com/benchmarks If you just need plaintext services, something like ~7 million requests per second is feasible at the moment. By being clever with threading primitives, you can preserve that HTTP framework performance down through your business logic and persistence layers too.
Thus, in my case those numbers might be closer to the following:
- plaintext: up to 2'500'000 requests per second, most technologies go up to around 500'000
- data updates: up to 14'000 requests per second (20 updates per request, so 280'000 updates per second)
- fortunes: up to 300'000 requests per second (full CRUD and sorting)
- multiple queries: up to 32'000 requests per second (20 queries per request, so 640'000 queries)
- single query: up to 530'000 requests per second, most technologies go up to around 100'000
- JSON serialization: up to 970'000 requests per second, most technologies go up to around 200'000
Of course, their setup also plays a part, since the VPSes that i'd go for probably wouldn't be comparable to a Dell R440 Xeon Gold.It's really nice to have this data, but the code that's written also plays a really big factor - i've seen people who write code with N+1 problems in it and call ORMs in loops and adamantly defend that choice because "such code is easier to reason about" instead of a simple DB view that would be 20-100x faster. With such code, it'd be closer to the "multiple queries" test.
Then again, these tests basically tell you that in 90% of the cases you should go for Java or .NET, abandoning Python, PHP and Ruby for them (though one could also introduce Rust into the mix and say the same), which realistically won't happen and people will use whatever technologies and practices that they feel comfortable with.
I've seen applications that work fine with hundreds of thousands of page loads per minute (multiple requests per load) and i've seen systems that roll over and die with 100 concurrent users, lots of variety out there.
Re: In defense of simple architectures
#194Earlier quoted context omitted.
It really has nothing to do with that. The slack client is just written poorly.
> The slack client is just written poorly. Why yes, Slack does seem to be written poorly - just as poorly as every other web app that I use including VS Code, Discord, MS Teams, etc.. Maybe the Slack developers are just stupid, uneducated, malicious, poorly managed, or ambivalent (or all of the above) but the platform does to be conducive to creating clunky and bloated software.
If you want bad examples of similar software, have a look at Brackets (https://brackets.io/index.html) and Atom (https://atom.io/).
Maybe things have improved in the past years, but last i checked Atom in particular was horrendously slow.
Re: In defense of simple architectures
#195Earlier quoted context omitted.
Perhaps other people don't find his writing uncompelling or read Wolfram-style self-regard into it.
Evidently. These two things can be true at once: Intelligent good people with good taste and good will find an author's writing compelling, interesting and valuable. Simultaneously, other intelligent good people with good taste and good will do not. It happens. Neither are wrong.
Re: In defense of simple architectures
#196Earlier quoted context omitted.
Evidently. These two things can be true at once: Intelligent good people with good taste and good will find an author's writing compelling, interesting and valuable. Simultaneously, other intelligent good people with good taste and good will do not. It happens. Neither are wrong.
Yes, that is a thing that has sometimes happened, though not in this case.