Posted by ingve 1 day ago
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.
The real nice thing about SQLite in prod though is how much it simplifies development and deployment. Let's be real, a lot of apps people build are relatively small, basic CRUD apps that see modest usage or are even internal-only, SQLite is perfect for that. And SQLite can scale reasonably well on modern hardware. It follows the premise of Rails quite nicely: it gets you up and running, scaling to the point you're making a decent amount of money and then you can figure out how to scale beyond that, if you need to.
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?