Posted by ingve 9/11/2025
It is implemented like this:
- The front end uses react to draw a UI.
- It fetches data from a JSON file stored on S3.
- When we get a write request, a lamdba function reads the JSON file, parses it, adds new data, and writes back to S3.
The main selling point for me is that almost all of it is static assets, which are cheap and simple to host, and the tiny bit of "back end" logic is just one nodejs function.
The previous implementation used SQLite and a golang back end, but I eventually got tired of having to maintain a virtual machine to host it.
I ever plan do it with sqlite, loading it at memory during app start and flush data to s3 during runtime but it create more corner cases and logic to handle.
What about all the important things you need in a database such as multiuser/remote access and other such things?
What do the "sqlite in production" people do when they need to examine the database/resolve an issue/do development? Also what about the limitations of sqlite in modifying database structure?
The simple answer to your question is you don’t. And if you do need them you don’t use SQLite.
Can you even redeploy a sevice like this without downtime?
Why can't you just use a copy of the database when you need to examine it or resolve issues?
None of these things have anything to do with being a "toy" app or not. They are matters of scale and business requirements. But that's the point isn't it? There are plenty of non-toy systems where none of these requirements apply.
Plenty of very successful business and applications could handle a brief downtime for deployment. Plenty don't need multiple users or remote access, plenty have reasonably small databases.