3 ms·
It is all reasonable stuff for most apps that don’t need scale EXCEPT writing files to disk as a database. Doing that for “blobby” stuff like profile pic is OK
by quickthrower2 3y ago
It is all reasonable stuff for most apps that don’t need scale EXCEPT writing files to disk as a database. Doing that for “blobby” stuff like profile pic is OK but for shared data that needs granular mutation I feel you will end up with a buggy, adhoc, ill specified half of postgres in your app.
- gunapologist99 3y agoIf you write data to a temporary file and then rename that file to its final name, renaming is an atomic operation on a POSIX filesystem, so you will cleanly overwrite the original file. However, you then need to deal with the risk of lost writes if another process or thread is reading/writing at the same time (i.e., sequential writes with in-memory cache, or just architect so that only one writer at a time; of course, if the shape of the data fits SQL and you don't mind compiling C libraries into your app which might remove the ability to static compile, using pure SQLite in WAL mode might be a better approach since it handles multiple writers for you.) Even with that risk, for certain types of apps, this can be a way to avoid a database which might need a separate process to backup/dump etc, the skills of a DBA-type of person in some environments, adding yet another database to an enterprise "approved" list, etc. This technique presents a nice, clean view of real data and allows backups of just the live data directory itself. On SSD, it's also much more performant than you might expect. It's quite possible to make the author's approach work very well with nearly zero long-term maintenance and no external database dependencies, as long as you are careful to manage the expectations and requirements.