I use https://github.com/ariga/atlas for this, migration based and schema base both has there good and bad side, I prefer both even in one project, schema based can make dev faster, eaiser, migration based make feel reliable.
Ariel from Atlas here. This setup is pretty common (declarative locally, versioned in real environments). Since migrations are auto-generated (by Atlas) on PRs, most developers never touch the versioned workflow directly.
I wrote a very rudimentary schema and automatic migration system for SQLite. One problem that I ran into recently was deploying changes that spanned two migrations, because the tool doesn’t know how to step through commits to do successive auto-migrations between schema versions. I guess there are rather obvious ways to handle this if you generate and then commit the full migration sql for each schema change. Nonetheless I’m curious if this is a problem you have had to think about, if you find it interesting or if it sounds like a bad path to go down, and if atlas does anything smart in this department. Thanks in advance!
Yeah, after looking more into sqldef and alternatives I stumbled on Atlas too and I like the explicit support for migration based flow for exactly the same reasons. I want to know exactly what kind of migration will be applied to my prod database beforehand.
So, the final choice is dexie + custom backend? I've researched these open source solution before, I think dexie is the choice that you will never regret.
When an API commits to /v1 it doesn't mean it will deprecate /v1 when /v2 or /v3 come out, it just means we're committing to supporting older URI strategies and responses.
/v2 and /v3 give you that flexibility to improve without affecting existing customers.
I used to use sqlite3 with stdio to read VoIP SQLite data. It's difficult or impossible to get a compatible SQLite version, and it's also hard to use cgo. I want to read the SQLite data on the server, and stdio is the only choice.
Bootstrap is a good practice in old time, tailwind is modern css, daisy ui is a battery included components in pure css based on tw. I use daisy ui in every project I work on, by using daisy ui, I don't need shadcn, I prefer <button> instead of wrap my own <Button>, and menu, dialog etc. With baseui components I have a very powerful toolset that let me build thing's fast and good enough.