> For example having database migrations built in etc. I actually went the exact opposite route, at least when possible: https://github.com/amacneil/dbmate htt

> For example having database migrations built in etc. I actually went the exact opposite route, at least when possible: https://github.com/amacneil/dbmate 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-framework-core-inside-rider-ui-way/#existing-database-scaffolding https://blog.jetbrains.com/dotnet/2022/01/31/entity-framewor... So in my case, I can have: * 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)!