4 ms·

At Standard Ebooks we serve a respectable number of page views and ebooks each month - and have been on the front page of HN three or four times - all of it don

by acabal 3y ago

At Standard Ebooks we serve a respectable number of page views and ebooks each month - and have been on the front page of HN three or four times - all of it done with a single 4GB VPS. And the only reason we upgraded to 4GB from 2GB is because we needed more RAM for the server to build the extremely large Decline and Fall of the Roman Empire ebook - if it weren't for that, our 2GB server would still have been just fine for all that traffic. I wrote a blog post about how we do it here: https://alexcabal.com/posts/standard-ebooks-and-classic-web-tech https://alexcabal.com/posts/standard-ebooks-and-classic-web-...

eyegor 3y ago
A lot of resources go to scaffolding for containers, runtimes, caching, etc. 4gb would make for a chugging experience if you run a Java spring boot backend for example. But an old school php + postgres stack would be fine, or modern dotnet, rust, etc. And honestly I'm not sure it matters since ram and compute is cheap for most small-medium sites (at worst maybe $30-50/mo vs $10-20/mo). VPS services are pretty cheap these days. Hetzner, digital ocean, genesis, etc. Or you spend a couple grand to build a dedicated machine in raid6 and only pay utilities.
- acabal 3y ago
  Of course. The entire point is that so much of that is just unnecessary for 90% of web projects. Most projects that are basically a front-end website backed by a local DB can get by on a 2GB VPS if they embrace classic web tech and don't get sucked in to whatever framework/cloud service/container craziness is hot this week. Once they start hitting millions of page views a month, we can talk about upgrading to 4GB :)
- LtWorf 3y ago
  Remember that rust doesn't catch all the memory leaks… So a long running rust process might degrade the performances in the machine, slowly.
  - pdimitar 3y ago
    If you can give examples on how does Rust leak memory, that would be informative. I had two services run uninterrupted for months in 2GB RAM containers. Memory increased steadily the first 5-10 minutes and then stayed there indefinitely long.
bysja 3y ago
Great book
jameshart 3y ago
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 https://fundraising.fracturedatlas.org, contribution management to https://github.com/standardebooks https://github.com/standardebooks, collaboration, membership and communication to https://groups.google.com/g/standardebooks 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.
- acabal 3y ago
  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#main-website https://github.com/standardebooks/web/blob/master/README.md#...
  - jameshart 3y ago
    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.
vinnski 3y ago
Oh man I absolutely love the work that you guys do. I'm actually in the process of learning Ebook production using the 'Step by Step' guide on your website. I'm essentially learning it all from scratch as I have little to no programming/SWE experience (I learned a bit of Lua because of KOReader[1]) but the technical side of ebook production has always fascinated me enough to keep learning. Also because I wanted to contribute more than just typos and grammatical errors (as important as they are). [1] https://github.com/koreader/koreader https://github.com/koreader/koreader

by acabal 3y ago

eyegor 3y ago

A lot of resources go to scaffolding for containers, runtimes, caching, etc. 4gb would make for a chugging experience if you run a Java spring boot backend for example. But an old school php + postgres stack would be fine, or modern dotnet, rust, etc. And honestly I'm not sure it matters since ram and compute is cheap for most small-medium sites (at worst maybe $30-50/mo vs $10-20/mo). VPS services are pretty cheap these days. Hetzner, digital ocean, genesis, etc. Or you spend a couple grand to build a dedicated machine in raid6 and only pay utilities.

acabal 3y ago
Of course. The entire point is that so much of that is just unnecessary for 90% of web projects. Most projects that are basically a front-end website backed by a local DB can get by on a 2GB VPS if they embrace classic web tech and don't get sucked in to whatever framework/cloud service/container craziness is hot this week. Once they start hitting millions of page views a month, we can talk about upgrading to 4GB :)
LtWorf 3y ago
Remember that rust doesn't catch all the memory leaks… So a long running rust process might degrade the performances in the machine, slowly.
- pdimitar 3y ago
  If you can give examples on how does Rust leak memory, that would be informative. I had two services run uninterrupted for months in 2GB RAM containers. Memory increased steadily the first 5-10 minutes and then stayed there indefinitely long.

bysja 3y ago

Great book

jameshart 3y ago

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 https://fundraising.fracturedatlas.org, contribution management to https://github.com/standardebooks https://github.com/standardebooks, collaboration, membership and communication to https://groups.google.com/g/standardebooks 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.

acabal 3y ago
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#main-website https://github.com/standardebooks/web/blob/master/README.md#...
- jameshart 3y ago
  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.

vinnski 3y ago

Oh man I absolutely love the work that you guys do. I'm actually in the process of learning Ebook production using the 'Step by Step' guide on your website. I'm essentially learning it all from scratch as I have little to no programming/SWE experience (I learned a bit of Lua because of KOReader[1]) but the technical side of ebook production has always fascinated me enough to keep learning. Also because I wanted to contribute more than just typos and grammatical errors (as important as they are). [1] https://github.com/koreader/koreader https://github.com/koreader/koreader