Pure SQL migrations, regardless of the back end technology that you use, completely decoupled from how each framework/library views things and therefore not dependent on them (you could even rewrite the back end in another technology later on, if needed; or swap ORMs; or avoid issues when there's a major ORM version update).
* a DB that has migrations applied with dbmate, completely decoupled from any back end(s) that might use it
* a back end that has entity mappings for ORM (if used) generated from the live local test database container during development, used for an API and not much more
* a front end that's typically a SPA using the API, but is otherwise just a bunch of prepared files that can be served off of any web server
Of course, if you need SSR then things move around a bit, but that decoupling works great for me (but might not for others)!
I actually went the exact opposite route, at least when possible: https://github.com/amacneil/dbmate
Pure SQL migrations, regardless of the back end technology that you use, completely decoupled from how each framework/library views things and therefore not dependent on them (you could even rewrite the back end in another technology later on, if needed; or swap ORMs; or avoid issues when there's a major ORM version update).
It's really nice when you can generate entity mappings based on a live database, like with https://blog.jetbrains.com/dotnet/2022/01/31/entity-framewor...
So in my case, I can have:
Of course, if you need SSR then things move around a bit, but that decoupling works great for me (but might not for others)!