Hacker News Reader

Comment by jameshart | Hacker News Reader

More applications should consider git as a content management database. It's great architecture. Statically serving files built by a CI process running on the server is very tidy.

But let's be clear, your serving infrastructure is able to be that simple because you outsource donation management to https://fundraising.fracturedatlas.org, contribution management to https://github.com/standardebooks, collaboration, membership and communication to https://groups.google.com/g/standardebooks, and marketing signup management to... looks like postmark.

So sure, you can run your stuff on a single server, but you're relying on a bunch of other people running much more sophisticated services on a lot more infrastructure in order to do it.

View on HN

Sure, at some point you're going to be relying on some 3rd party somewhere. We use a VPS and not a bare-metal hand-installed rack, and we rely on an electrical company and not a hand-turned crank to power our servers. As far as email goes, It's simply not possible to self-host transactional email in 2024 if you want it to arrive in an inbox and not a permanent spam blackhole; this is a people problem and not a technical one. Likewise, another people problem is that it's not possible to accept money online without involving a 3rd party service like Fractured Atlas or Stripe or PayPal.

(Moving away from GitHub towards a self-hosted Git solution, and away from Google Groups to a self-hosted mailing list, is actually on our long-term todo list[1]).

All those things don't mean one can't run one's web app on a single tiny server, like we do. I still argue that outsourcing the basic fundamentals of one's web app, like the OS, runtime, or database to some cloud service, or resorting to flavor-of-the-month frameworks or containers, or doing silly things like using Javascript to render one's entire frontend, often simply result in complexity, slowness, and bloat.

[1] https://github.com/standardebooks/web/blob/master/README.md#...

Fully agree and endorse.

But my point is... those are all web applications too, and they don't have the option of outsourcing everything. Someone has to build a system that does more than just serve static files.

The claim that 'the majority of web applications can run on a single server' is kind of belied by the example of a site where not even the majority of sub-applications that are required to provide the full functionality of the system are running on a single server.

Of course! Stripe, Paypal, Postmark/Sendgrid/whatever are not part of the majority I'm talking about. (Although Fractured Atlas, which is merely a wrapper for the Stripe API, is; we use it because it solves a people problem, not a technical one.) There are certainly projects and businesses that will require many high-power servers and more complex technical machinery than basic LAMP. However most people on HN are not developing the next Stripe, even if they don't realize it yet.

Those other workloads don't sound particularly taxing to me. Many get very sparse traffic; hosting a donation page, web newsgroup/discussions, and user management need not drastically scale up the serving footprint here.

Those hosted services mainly are about not needing to pay the human management/ownership costs.

The real win this architecture has is outsourcing its content management database to GitHub. That's where all the complicated stuff like permissions and authentication and change notifications and approval workflows, that make up the bulk of complexity in most bespoke business applications, as well as all the tricky stuff of managing the actual files that the contributors are managing, is all happening. It's a smart decision! There's a lot involved in running a system like that reliably - outsourcing it is a great idea.

If they were to do that in house, by switching to a self-hosted GitLab, say, well... that could be run on a single machine (https://docs.gitlab.com/ee/administration/reference_architec...) at the cost of having to manage scheduled downtime for upgrades. If the user base or activity level grew beyond what that server could handle (and given that the intention of this project is to cultivate an ever growing community of contributors that might be a concern)... the next stop up is an eight node system: https://docs.gitlab.com/ee/administration/reference_architec....

Again though, that's not actually computationally expensive. It's just hard to get right & maintain, with few do-all open-source offerings ready to stand in. It's not like having 10x the computing resources at hand would highly motivate someone to bring it onboard: it's a difficult thing to manage well, but not actually computationally expensive to do so.

Reply on news.ycombinator.com