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

31–40 of 196 posts

Re: In defense of simple architectures

#31

Post by exfascist »

spicybright wrote: post #28
exfascist wrote: post #18

Earlier quoted context omitted.

When you type something into IRC that message shows up in the log and every online users client pretty reliably. Furthermore the high degree of diversity among clients provides a pretty extreme amount of client side functionality that Slack completely lacks (scripting is a huge one.)

I love irc, but is is just silly. Slack has much better history because you don't need to have been online when messages are sent to log them. Slack is absolutely more reliable in this regard. IRC is easy to script because the protocol is so simple. But you leave so much on the table for that cost. Obviously if your use case is text only that you don't care about being persistent and you lean heavily on scripting to…

IRC has logs for history, they're fast and you can run your own logger to control the retention policy if you want. These heavy weight IM tools have extremely short log retention (months) and searching through the logs is extremely slow and frustrating IME.

Re: In defense of simple architectures

#32

Post by syngrog66 »

winrid wrote: post #10
taeric wrote: post #2

My favorite trap in all of this, is that this thinking will fail most tech interviews. It is incredibly frustrating.

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

Re: In defense of simple architectures

#33

Post by woah »

ryanbrunner wrote: post #7

I think especially for small teams starting out, complex architecture can be a huge trap. Our architecture is extremely simple and boring - it would probably be more-or-less recognizable to someone from 2010 - a single Rails MVC app, 95+% server-rendered HTML, really only a smattering of Javascript (some past devs did some stuff with Redshift for certain data that was a bad call - we're in the process of ripping that…

That doesn't sound like it's really any simpler than a json API server (written in node, python, go, or anything else), and a SPA. Maybe the lesson is "build with what you know if you want to go fast".

Re: In defense of simple architectures

#34

Post by pavlov »

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 quickly, but turns out they do the job for these small businesses and need very little maintenance. Moving the app to a new server instance is dead simple because there's basically just the script and the data file to copy over, so you can do OS updates and RAM increases that way. Nobody cares about a few minutes of downtime once a year when that happens.

There are good reasons why we have containers and orchestration and stuff, but it's interesting to see how well this dumb single-process style works for apps that are genuinely simple.

Re: In defense of simple architectures

#35

Post by zozbot234 »

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.

Postgres supports sharding out of the box. The documentation tells you how to do it, using foreign data wrapper and table partitioning.

Re: In defense of simple architectures

#36

Post by DerArzt »

danielvaughn wrote: post #11
ilovecaching wrote: post #8

The vast, vast, vast majority of organizations don't need micro services, don't need half of the products they bought and now have to integrate into their stack, and are simply looking to shave their yak to meet the bullet list of "best practices" for year 202X. Service oriented architectures and micro services solve a particular problem for companies that are operating on a massive scale and can invest (read waste m…

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.

Re: In defense of simple architectures

#37

Post by ryanbrunner »

woah wrote: post #33
ryanbrunner wrote: post #7

I think especially for small teams starting out, complex architecture can be a huge trap. Our architecture is extremely simple and boring - it would probably be more-or-less recognizable to someone from 2010 - a single Rails MVC app, 95+% server-rendered HTML, really only a smattering of Javascript (some past devs did some stuff with Redshift for certain data that was a bad call - we're in the process of ripping that…

That doesn't sound like it's really any simpler than a json API server (written in node, python, go, or anything else), and a SPA. Maybe the lesson is "build with what you know if you want to go fast".

In my experience SPAs bring a lot of headaches that you just don't really need to think about with traditional HTML. Browser navigation, form handling, a lot of accessibility stuff comes out of the box for free, and there's one source of truth about what makes a particular object valid or how business logic works (which is solvable in the SPA world but brings a lot of complexity when you need to share logic between the client and the server, especially when they're in different languages).

Frankly out of all the things that make our architecture simple and efficient, I would say server rendered HTML is by far the biggest one.

Re: In defense of simple architectures

#38

Post by guelo »

WJW wrote: post #22
snvzz wrote: post #15

Earlier quoted context omitted.

Slack comically uses gigabytes of RAM and plenty of CPU time in the client side.

Wtf are you doing with it? My slack instance (on linux) is resting around 300 MB resident set size and 0% cpu. 300 MB is still a lot for a chat app, but it is definitely not gigabytes.

Make sure you're counting all the sub-processes it spawns (at least on Mac, don't know about linux)

Re: In defense of simple architectures

#39

Post by nomemory »

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…

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 or Facebook.

Re: In defense of simple architectures

#40

Post by sitkack »

musicale wrote: post #16
snvzz wrote: post #15

Earlier quoted context omitted.

Slack comically uses gigabytes of RAM and plenty of CPU time in the client side.

It's a nice demonstration of the efficiency of web apps vs. native apps.

It really has nothing to do with that. The slack client is just written poorly.
Post reply on HN