the web server deployment model breaks at hobby scale

2026-08<br>the web server deployment model breaks at hobby scale

lets say you want to make a web thing that you intend other people to host on their own servers. unfortunately, by thinking this very thought you immediately locked your codebase out of several efficiency tricks other software intended to be hosted privately can make use of, and you have now burdened yourself with reinventing several wheels others have already done better.

let’s start out with a baseline, which we’ll add to as requirements change:

something to take care of tls

separate from the application so your private keys aren’t exposed wider than necessary

lets you change how you get your certs without impacting application code

the app

in pretty much every case, the first bit will likely also be a relatively capable web server that includes reverse proxying as one of many features. one very common feature is to serve static files, which is currently handled by your application.

#static files

it’s not a bad idea to offload static file serving to the reverse proxy. it’s implementation will likely be way better than whatever comes with the hip new framework you chose, and even if not, static files will no longer clog up the mediocre amount of requests your python or node web server can handle concurrently. you attempt this.

if either one of your app or the reverse proxy is containerized or otherwise compartmentalized, every admin setting up your application now has to poke a hole in one or both of these compartments to let the reverse proxy access the static files distributed with the app.

once your app is finally released, you get an issue report from someone whose reverse proxy is one of those “cloud native” ones that does nothing but reverse proxying and is only distributed as part of kubernetes. you dejectedly add back in an option to let the app serve the files, which everyone turns on the instant they realize it exists. you weep as you realize you have contributed to the fair share of inefficiency bogging down the potential of the lower end hardware your target audience has access to.

in “professional” scale? static files are deployed completely separately, likely to an s3 bucket or somesuch and fronted by an Actual Cdn™, so this issue never comes up.

#unauthenticated caching

you recognize your application will get a lot of unauthenticated visits, either by humans or bots. unauthenticated visits always get the same response, so there’s no real reason to re-compute these responses if nothing changed. you determine that an hour is an adequate amount of time for a “stale” page in your context.

you look fondly at the vinyl cache website, with full knowledge you can’t actually require it as you’re just one part of the already existing rube goldberg machine of a hobbyist’s web server.

dejected, you add the necessary cache-control and vary headers to your endpoints. you find out about no-vary-search and realize it’s chrome only. you know the exact set of query parameters that will change the response, but there’s nothing to do from where you are. if you could depend on vinyl, you could trim out the unused query parameters, so annoying people trying to resurrect a dead joke about link previews don’t try to bypass your cache by adding ?qweqweawe after your links.

you find out your web server library has a caching middleware. you read through the features it supports and realize it doesn’t support anything other than cache-control‘s ttl and perhaps vary if you’re lucky. you add it in, with nothing but a glimmer of hope in your heart that nobody tries anything funny. you put a configuration switch and documentation in hopes that admins who already have a good cache set up will tweak it for best efficiency. they don’t

once your app is released, you get an issue from a caddy user, because they trusted caddy’s unbelievably mediocre caching plugin which will gladly corrupt responses if it feels like it. someone else has enabled nginx’s cache but their install keeps getting bogged down anyway because they forgot to enable proxy_cache_lock. someone else has put their site behind cloudflare but enabled your cache option as well because they didn’t have a cache set up on their own machine. you cringe at the amount of memory wasted.

you also realize your builtin caching middleware is caching your static files. serving those are relatively trivial and likely already cached by your OSs disk caching facilities, so you’re just bloating your memory for nothing. because your middleware only looks at cache-control, you can’t do anything without preventing browsers from also caching your best-practice immutable static files on the client’s end. you weep.

in “professional” scale? they control the entire machine, so they can indeed set up vinyl or something along it’s lines and tune it for the exact cache behavior they want. well, ok, they probably outsource it to a cdn which does a...