Hosting arbitrary static sites

The backend for this site currently serves four static sites: this blog and three Vieter sites, namely its documentation, API documentation and manpages. These can be updated by POSTing tarballs containing the static files to the backend. This all works fine, but the API sucked and the four static sites were hardcoded, meaning it wasn’t possible to add new sites without recompiling the backend.

The old API

My original choice for this API was rather strange in my opinion. There was a single route, /api/deploy, where tarballs could be uploaded to, along with an optional query parameter specifying which of the sites the tarball contained. If the parameter was omitted, it defaulted to the “root site”, meaning the blog.

This design choice always felt strange to me, but I didn’t care enough to change it. Until now.

In with the new

The new design is in my opinion a lot more clean and straightforward. I can push a tarball to any route, e.g. /docs/vieter and the contents of the tarball will be mounted there. The server simply unpacks the tarball at the specified path and functions as a simple file server. Updating a directory overwrites its contents without checking if anything is overwritten, meaning I do need to watch out I don’t accidentally publish sites to subdirectories of other sites. If I do, they will be removed every time the parent directory is updated.

An important caveat here is the root directory. The above method would imply that updating / would overwrite all other sites every time, which is bad. To prevent this, a site uploaded to / (or /_root) is instead stored in _root on disk. When serving a file, the server first looks in the /_root directory first, and in the other directories if no file is found.

This setup allows me to create as many static sites as I want and host them on subpaths of my domain with ease. I hope to use this feature some time this year!

Jef