Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Defense of Simple Architectures (2022)

danluu.com

Post reply on HN
Print view View original

441–447 of 447 posts

Re: In Defense of Simple Architectures (2022)

#441

Post by mleonhard »

> We’re currently using boring, synchronous, Python, ... We previously tried Eventlet, an async framework ..., but ran into so many bugs ...

I had a similar experience using async Rust to make a boring HTTP server. Debuggers can't trace across `await`, so debugging was a very slow manual process. Also, I wasted a lot of time dealing with borrow-checker errors.

I finally gave up and tried using Rust HTTP servers that let you write threaded request handlers, but there was only one (Rouille) and it had show-stopping problems. So I wrote a good one:

https://crates.io/crates/servlin

You can use Servlin to make a boring HTTP server in Rust, with threaded request handlers (no async). I use Servlin to serve https://www.applin.dev , running on Render. I'm also using Servlin (and Applin) to build a mobile app.

Re: In Defense of Simple Architectures (2022)

#443

Post by begueradj »

from-nibly wrote: post #51

This is what I tell engineers. Microservices aren't a performance strategy. They are a POTENTIAL cost saving strategy against performance. And an engineering coordination strategy. Theoretically If you have a monolith that can be scaled horizontally there isn't any difference between having 10 replicas of your monolith and having 5 replicas of two microservices with the same codebase. UNLESS you are trying to undersc…

Keep it simple :)

Re: In Defense of Simple Architectures (2022)

#444

Post by huntoa »

When I think financial services and simple architecture, I think of Python, ORM, Kubernetes, Cloud, GraphQL and admission of "data-integrity bugs" and "paying retail public cloud prices".

The article itself mostly discusses tech choices rather than architecture. Half of their choices, they seem to regret.

On the service itself: It seems detrimental for African countries (or any country) to allow external financial services to get ingrained and allow them to milk their own populace and prevent the development of state-owned, cost-neutral, non-profit, long-term solutions for the public good. Payment should be public infrastructure, not private profiteering.

Is anyone here donating Dan $180k/year (+VAT) for his blogging?

Re: In Defense of Simple Architectures (2022)

#445

Post by nijave »

jen20 wrote: post #390
nijave wrote: post #117

Earlier quoted context omitted.

You don't need it but you can also explode your repo, test, and build complexity when it'd be easier to keep them isolated. For instance, you might not want to require all develops have a C tool chain installed with certain libraries for a tiny bit of performance optimized code that almost never gets updated.

One would imagine that by 2024 there would be a solution for every dynamic language package manager for shipping pre-compiled native extensions, _and_ for safely allowing them to be opted out of in favour of native compilation - I don't use dynamic languages though so don't really know whether that has happened. My overriding memory of trying to do literally anything with Ruby was having Nokogiri fail to install beca…

I think it's gotten a little better but is still a mess. I think the biggest issue is dynamic languages tend to support a bunch of different OS and architectures but these all have different tool chains.

Nodejs, as far as I know, ships entire platform specific tool chains as dependencies that are downloaded with the dependency management tool. Python goes a different direction and has wheels which are statically linked binaries built with a special build tool chain then hosted on the public package repo ready to use.

I don't think anything in Ruby has changed but I haven't used it in a few years.

Re: In Defense of Simple Architectures (2022)

#446

Post by nijave »

dns_snek wrote: post #210
nijave wrote: post #117

Earlier quoted context omitted.

You don't need it but you can also explode your repo, test, and build complexity when it'd be easier to keep them isolated. For instance, you might not want to require all develops have a C tool chain installed with certain libraries for a tiny bit of performance optimized code that almost never gets updated.

I don't know, that seems like confusion of runtime and code organization boundaries. Adding a network boundary in production just to serve some code organization purpose during development seems completely unnecessary to me. For development purposes you could build and distribute binary artifacts just like you would for any other library. Developers who don't touch native code can just fetch the pre-built binaries co…

>Adding a network boundary in production just to serve some code organization purpose during development seems completely unnecessary to me.

That's a pretty common approach. Service oriented architecture isn't necessarily "development" purposes, usually more generic "business" purposes but organization layout and development team structure are factors.

From an operational standpoint, it's valuable to limit the scope and potential impact code deploys have--strong boundaries like the network offers can help there. In that regard, you're serving a "development" purpose of lowering the risk of shipping new features.

Re: In Defense of Simple Architectures (2022)

#447

Post by Lacusch »

notapoolshark wrote: post #202

Agree with this article 100%. At my old company we chose to write our server in Go instead of Java. We ended up regretting it because it was significantly harder to hire developers who could write in Go vs. Java. Later, I read a Paul Graham essay where he says that a company should choose its programming language based on how fast they can iterate in that language. And it clicked for me.

When did this happen? From what I head and what I see go is starting to get quite popular. Not Java level of course but it shouldn't be impossible to hire go devs now. Especially that it's not the hardest language to learn.
Post reply on HN