One thing I've found over the years (particularly after pivoting away from web dev for awhile and toward ERP and WMS development) is that the data is ultimately

One thing I've found over the years (particularly after pivoting away from web dev for awhile and toward ERP and WMS development) is that the data is ultimately what's going to drive everything. Consequently, my philosophy has kinda shifted away from a "let's build an app and bolt some DB onto it with an ORM" and more toward "let's build a DB (schema) and build the app around it". This has some implications: - An ORM is rarely necessary or even desirable. If I'm using a SQL database, I'm very much inclined to stick with SQL (or maybe a thin ORM if it gives a lot of bang for my buck and stays true to SQL's semantics). - I only really need or want about 10% of a web framework, and that's primarily routing and templates. Once I'm using SQL directly, it's pretty straightforward to just... query directly for exactly what I want to feed into a template, or feed (sanitized!) input directly into a prepared statement. Consequently, the "controllers" are basically just there for access control and maybe some caching. - The database ends up being the thing driving business logic. This means actually writing triggers, functions/sprocs, etc. and letting the DB be in control of its data and the manipulation thereof. - Hell, any SQL DB worth its salt these days can query and generate JSON directly. This means a REST API can exist almost entirely as sprocs, and the "web" part boils down entirely to "receive request, feed into sproc, return output". The main downside of this (besides needing to be really comfortable with SQL) is that this approach puts more strain on the DB servers. Easy to fix, though: shift resources away from the web servers (ain't like they need it) and toward the DB servers.