Live data from Hacker News

In defense of simple architectures

danluu.com

191–196 of 196 posts

Re: In defense of simple architectures

#191
post #34

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…

Totally agree with simple architecture for simple and small use cases. Just curious to know, are you running any small businesses this way?

Re: In defense of simple architectures

#192
post #36

Earlier 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.

Bit late, but is it worth cutting up? Sunk cost I imagine will sting but simplifying might get rid of a lot of the fear.

Re: In defense of simple architectures

#193

Earlier 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.

Their benchmarks are also really cool because you can choose to filter down technologies by what you personally know or just want to compare, for example: https://www.techempower.com/benchmarks/#section=data-r20&hw=...

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

#194
post #40

Earlier 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.

While i agree with your overall point, i think that VS Code is one of the better (only?) examples of really good web technology based software. It's snappy, reliable and has very few bugs.

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

#195
post #185

Earlier 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.

Yes, that is a thing that has sometimes happened, though not in this case.

Re: In defense of simple architectures

#196
post #195

Earlier 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.

Ah, I see. If anyone doesn't appreciate his work sufficiently, they are not only wrong, but probably stupid or crazy if not outright evil.
Post reply on HN