Standard Ebooks runs everything on a 2 GB VPS with no database and almost no JavaScript
They’re keeping the tech simple. They build ebooks and then distribute them.
One single-core server hosts all of their Git repos, builds their ebooks and serves their web site.
Alex Cabal says the web site runs on a “classic LAP stack.” It’s missing the “M,” meaning no MySQL — and no database at all.
And the tech is based on PHP. No frameworks.
And it runs fast because all (at the time of the post’s writing) 630 ebooks could fit in memory:
It turned out that for our small data set and very basic data processing requirements, this approach is perfectly performant. Of course, we’ll eventually reach a point where we’ll need a real database, but we’ll probably reach that point first because we want our website to do more complex things, not because the size of our ebook corpus calls for one.
And in the meantime, we’re still serving millions of page views just fine.
Also: No JavaScript:
JS frameworks do make sense for some larger, very complex apps. But so few websites are legitimately very complex apps. More often than not, they’re just another CRUD app—the kind of document-based, asynchronous model that the classic web was designed and built for.
And while it may seem faster to develop a new project by starting with a JS framework, it may be just as fast to develop a new project starting from a server-side framework for your language of choice.
And: No cloud:
The big benefit of running a basic Linux box on our own VPS is that everything is just files on a generic, well-understood platform. For the most part, Ubuntu at one host is going to be the same as Ubuntu on another one, and Ubuntu is Linux so jumping to (say) CentOS isn’t a huge leap. These skills are highly transferable, making it much easier to move a project somewhere else, or upgrade a server if our needs outgrow its muscle.
Lots of people also choose a cloud service because their CDNs can improve request speed. While that’s certainly true, SE’s classic-web approach makes that much less important. Modern web apps have grown to be so bloated in asset size, and spend so much time processing JS, that using a CDN to shave a few milliseconds off of fetching a static asset becomes a lot more valuable to them. But since we carefully control the size and amount of static assets we serve, and just send complete pages back to the client instead of relying on JS to render a page, shaving milliseconds all of a sudden seems much less important. And if the website’s a touch slower at geographic locations far from our host, well, we’re serving free ebooks here—it’s not life-or-death.