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

In defense of simple architectures

danluu.com

Post reply on HN
Print view View original

131–140 of 196 posts

Re: In defense of simple architectures

#131

Post by eternityforest »

cameronh90 wrote: post #67
bob1029 wrote: post #9

I think the biggest problem for most developers is not understanding what one computer can actually do and how reliable they are in practice. Additionally, understanding of how tolerant 99% of businesses are to real-world problems that could hypothetically arise can help one not frustrate over insane edge case circumstances. I suspect a non-zero number of us have spent time thinking about how we could provide determi…

These requirements don't come out of nowhere. Normally they come from: 1. CEOs/whoever that don't listen to how much additional complexity it is to build a system with extremely high uptime and demand it anyway. 2. Developers with past experience that systems going down means they get called in the middle of the night. 3. Industry expectations. Even if you're a small finance company where all your clients are 9-5 and…

If the additional complexity is just "Use this premade thing" and it only adds a half hour here and there of work, while also giving you essentially a premade and pre-documented workflow than new people will instantly know(Whatever your "bloated" tool tells you to do), then it might be a net win anyway.

If the extra complexity is microservices and containers you might have an issue, but microservices are kind of a UNIX philosophy derivative, I'm not sure the complexity is really intentionally added(Like when someone uses an SPA framework or something), it just kind of shows up by itself when you pile on thousands of separate simple things without really realizing the big picture is a nightmare.

Re: In defense of simple architectures

#132

Post by mbrodersen »

pavlov wrote: 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…

I suspect that 95% of business applications could be implemented just fine with that architecture. However I would use SQLite instead of a plain file. Just for added commit safety.

Re: In defense of simple architectures

#133

Post by mbrodersen »

powersurge360 wrote: post #92
uuyi wrote: post #88

Earlier quoted context omitted.

I would love to see more stuff like that. An application I have written recently for personal use is a double entry accounting system after GNUcash hosed itself and gave me a headache. This is based on Go and SQLite. The entire thing is one file (go embed rocks) and serves a simple http interface with a few JS functions like it is 2002 again. The back end is a proper relational model that is stored in one .db file. I…

Check out alpinejs or stimulusjs and combine it with htmx to get to a SPA like experience with very little additional complexity! Htmx let’s you serve partials over the wire instead of a page load so you can update the page incrementally and alpine and stimulus are both tools to add JS sprinkles like you’ve described in a way that is unobtrusive.

Adding dependencies is the opposite of simple.

Re: In defense of simple architectures

#134

Post by deterministic »

reggieband wrote: post #55

I understand his point but I actually think micro-services can be simpler than monoliths. Even for his architecture, it sounds like they have an API service, a queue and some worker processes. And they already have kubernetes which means they must be wrapping all of that in docker. It seems like a no-brainer to me to at least separate out the code for the API service from the workers so that they can scale independen…

It is pretty much impossible for a micro-service architecture to be simpler than a well designed monolith. To create a micro-service architecture from a well designed monolith you need to take the N libraries the monolith is built from and add protocols/serialisation/deployment etc. to each library. Each of which adds new distributed failure scenarios you now have to test/handle.

Re: In defense of simple architectures

#135

Post by mbrodersen »

jameshart wrote: post #115

This doesn't sound very simple at all. It's a single codebase that handles all your mobile API interactions, authentication, account management, presumably usage tracking and notifications, and all your offline processing, all interacting with a single database and queue infrastructure? And that same codebase marshalls all that through a GraphQL API and implements a custom data protocol? And you're calling that simpl…

I have worked on massive well designed monoliths and they were so much easier to maintain than equivalent micro-service implementations would have been. Monoliths and Micro-services will be easy/hard/impossible to maintain depending on how well they are designed. Not depending on whether it is a monolith or micro-service architecture.

Re: In defense of simple architectures

#136

Post by danrocks »

syngrog66 wrote: post #32
winrid wrote: post #10

Earlier quoted context omitted.

Yep. Failed an interview because I used EJS (SSR) and Node to build a simple Twitter in 30mins. The interviewer saw that it was three files and did not seem impressed. I guess they wanted me to use lots of little components in an SPA which I did in my day job, but it didn't seem nessisary for the task...

3 files? "Luxury!" I could implement a Twitter in 1 Python or Go file, hosted on 1 machine granted its concurrent user capacity and traffic load capacity would be insufficient for actual Twitter. but all the basics would work, in the small

You had a machine?

LUXURY!

Re: In defense of simple architectures

#137

Post by ta988 »

treis wrote: post #66
woah wrote: post #46

Earlier quoted context omitted.

Probably depends on the requirements. If the product should basically feel like a static web page, and you are OK making design and product decisions that work easily in that paradigm, then a server side framework built to make static web pages is going to be simpler. If you have product or design requirements that it should feel more dynamic like a native app, then trying to patch that on top of a static webpage mig…

IMHO the important thing is where your data is. If can all be client side then write a SPA. If it's on the server then the more you do on the server the better. Returning HTML and doing a simple element replace with the new content is 99.9% indistinguishable from a SPA.

And in Rails 7 with hotwire, it is really looking close to a SPA.

Re: In defense of simple architectures

#138

Post by ta988 »

syngrog66 wrote: post #32
winrid wrote: post #10

Earlier quoted context omitted.

Yep. Failed an interview because I used EJS (SSR) and Node to build a simple Twitter in 30mins. The interviewer saw that it was three files and did not seem impressed. I guess they wanted me to use lots of little components in an SPA which I did in my day job, but it didn't seem nessisary for the task...

3 files? "Luxury!" I could implement a Twitter in 1 Python or Go file, hosted on 1 machine granted its concurrent user capacity and traffic load capacity would be insufficient for actual Twitter. but all the basics would work, in the small

I'm sure there are horrible kubernetes deploys out here that you can deploy with a good ol' curl | sudo

Re: In defense of simple architectures

#139

Post by ta988 »

endisneigh wrote: post #29

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

We are serving a several tens of TB database with tens of thousands of daily user doing very heavy queries on a single machine that did cost us $15k a few years ago (we have fallbacks and replication and whatnot don't worry). The same machine also has java services. You can really do a lot on today's machines.

Re: In defense of simple architectures

#140

Post by rendall »

wackget wrote: post #110

I don't know how the author can claim that they run a "simple" architecture. From their job pages: Our stack : backend: Python 3 (+ mypy) API layer: GraphQL android frontend: Kotlin/Jetpack iOS frontend: Swift/SwiftUI web frontend: TypeScript/React database: Postgres infrastructure: GCP / Terraform orchestration: Kubernetes That is not simple by any stretch of the imagination.

How would you simplify this?
Post reply on HN