| I agree wholeheartedly with all of the points made in the article, but this website kinda sucks as an example. - The website is "one binary", but the deploy strategy involves compiling it instead of running a binary artifact - Won't rely on github pages, but depends on external resource at openlibrary.org - Writing your own stuff lets you take advantage of open standards, but the .html files in thoughts/ are structured as plaintext with a false file extension - When people go this route, they usually try to cram everything into the initial page load. This has several static files served dynamically. - The Golang code does not cache any responses, and does not store templates in memory. - Several dependencies in the go.mod file, all of them seem unused? Most importantly:
No discussion about the technical benefits of the "single-binary" ethos compared to modern infrastructure. It's my humble opinion that it's a great idea, and this is a poor example. |
It's a single binary working with the filesystem.
All content is on the filesystem.
The "single binary" is a lightweight golang webserver that serves content from the filesystem.