// The big picture server-side thing
// Docker images used
- alpine
- alpine/git
- gcr.io/distroless/nodejs20-debian12
- gitea/gitea
- neilpang/acme.sh
// npm packages used
- @conduitry/autocache @ 0.1.7
- @conduitry/eslint-config @ 0.0.0
- @conduitry/svelte-tiny-spa @ 0.0.0
- defiler @ 2.2.2
- devalue @ 4.3.2
- html-minifier @ 4.0.0
- katex @ 0.16.10
- lightningcss @ 1.24.1
- marked @ 12.0.1
- mime @ 4.0.1
- resolve.exports @ 2.0.2
- rollup @ 4.14.3
- svelte @ 4.2.15
- terser @ 5.30.3
// How this works
On the build side
Very little data crunching is actually done on the server that is sending you these pages — almost everything is precomputed/precompiled on the build server — i.e., my personal computer.
A bunch of custom string wrangling happens as part of the build process to turn various text files into the things web apps here consume.
Some custom building/compiling/minifying of everything also happens using the above tools during the build.
All the JavaScript is going through Rollup, and everything is coordinated using my homemade build tool — Defiler.
Everything has ETags generated and is then brotli-compressed and written out into one big data file which, along with some other things, is then deployed to the server.
On the server side
Everything lives in a number of Docker containers.
The actual web server reads the previously mentioned big data file into memory (it isn't that much data), and then happily blindly spits out data based on the request URL, without needing further disk access for most requests.
Larger things, like most images and downloads, live as regular files on the server, and are streamed to the client as required.
These files are indexed along with ETags in that main data file that is read into memory, so no disk access is required for requests returning 404 or 304.
Still other things, like the private Git server, live in their own Docker containers and volumes, and are proxied to by the main web server process.
The end