My perspective here was that 1 database query implemented by a framework with: good caching, perhaps canonicalisation to ensure small caches (e.g. query paramet

My perspective here was that 1 database query implemented by a framework with: good caching, perhaps canonicalisation to ensure small caches (e.g. query parameters ordering?), the right database indexes, the right response behaviour, etc, would be fine, but implementing this well in a middleware added by developers using a framework would be hard to do well and could be significantly higher cost. In my experience, implementing things like access control, requiring a single database query, in a middleware that applies to every request, does actually become a noticeable overhead and problem at some point. Sure many pages might be doing 20 queries so adding one more isn't a problem, but at some point there might be an API that needs to respond quickly, does <1 query on average with caching, and therefore has _double_ the cost with this feature. Because the URLs are supposed to be opaque in the general case, this still needs to be applied everywhere. This can definitely all be optimised, but I think doing this at the framework level is a much better solution.