4 ms·
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 st
by tetsuhamu 3y ago
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.
- tetsuhamu 3y agoIt's not actually a single binary. 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.
- dsQTbR7Y5mRHnZv 3y agoNo it isn't. You can try compiling from source and running it yourself: https://git.j3s.sh/j3s.sh/tree/c4517e8484a68c734d2f17c17c5468bfe09f0577/ https://git.j3s.sh/j3s.sh/tree/c4517e8484a68c734d2f17c17c546...
- shhsshs 3y agoThe code uses `//go:embed` which actually embeds a fake filesystem into the binary. It’s really easy to miss that part, but it truly is one single binary, despite seeming to reference files by paths.
- tetsuhamu 3y agoOh dang, that's neat! Thank you!