Hacker News Reader

Comment by bttf | Hacker News Reader

I've been working on a project that largely addresses this need. It's a distillation of knowledge gained from building web apps of my own as well as for startups for the past several years. The stack comprises of React (via NextJS), GraphQL, Express, Node.js, and PostgreSQL - all written w/ TypeScript.

The goal was to provide a hardened boilerplate app with no distinct featureset but at a minimum have things like ORM, user authentication, migrations, as well as a frontend web UI set up so that it could be used as a head-start for any web app projects in the future.

It's built for fast developer experience, while decoupled enough (a la containers) so that it can easily be taken into a kubernetes cluster for scale. (Still a monolith though.)

The project is private now, but happy share it on request. Also happy to answer any questions.

View on HN

This sounds right up my alley honestly, could you explain a bit more about the affordances you set up for the decoupled container component to allow it to grow from a few containers to an orchestrated K8s cluster? Just some insight into how and when one decides to grow from a container or two to full on clusters would be really good to know.

As for sharing, while it's very generous of you to offer access and I'm certainly interested in using it once it gets a public launch, I'm much more in pursuit of the thinking behind system design choices and better developing the intuition that makes those choices. Honestly the framework you're putting together sounds like it could help a lot of people with similar problems to me though :D

Sure; because it is a monolith, it makes things simpler by having just the one backend container to scale. So it's a matter of making more instances of it available (via # of pod replicas in your k8s cluster) for increasing availability.

You can start using k8s right away, and just have 3 replicas running to start. As you scale, just up the number of replicas (and nodes as you need them) as you go.

Your real bottleneck becomes the database at that point (in addition to any blocking 3rd party APIs you may be using), which I would not host in k8s but use a managed service such as AWS RDS. This bottleneck will make itself apparent later on, depending on your application and the scale you reach. But you should definitely have the resources to cross that bridge once you, if ever, reach it, because you should be dealing with a large number of customers at that point.

Ah gotcha yeah at the small scale(?) scaling we're talking about monolithic applications, being a bit simpler to organize and run, do still make for a compelling solution. That's a great tip regarding how to handle ballooning storage issues via managed cloud offerings (in the weird case I make something that really works) that I hadn't considered. However, it's starting to feel like these scaling questions/solutions are a lot more akin to Factorio bottleneck chasing than I would like haha.

Reply on news.ycombinator.com