I've been trying to think about access control and data access patterns for ByteCode.news.
One of the initial designs was based around having pluggable UIs. The actual app is a set of REST endpoints with as complete a specification as I could work out (and it's published at https://api.bytecode.news). UIs would be able to do whatever they wanted, however they wanted, as long as they interacted with the REST endpoints.
That way, they could show off their design strengths with a common base; there'd be a reference UI that showed how the UI was supposed to work (although not how it should look, because the reference UI is pretty grody) and people with better design skills than I could flex and create something awesome. Then the top-level domains could point to the "best of breed" UI and thus people would get whatever "won" while others still got to show off what they were good at doing.
But this is fundamentally limiting for some UI designs: it means that there's a layer between the data and the application. For, say, Primate, there's an expectation that it has access to the data - JavaServer Faces and Spring, with Thymeleaf, would all have the same problem, where optimally they have direct access to the data and could render it quickly and directly.
There's nothing preventing Primate or JSF or a Spring-hosted UI from using the REST endpoints, of course, in various ways, but it's a fundamental limitation that cripples those technologies from a "best of breed" perspective: they'd be serving as go-betweens between the user and the actual application.
So maybe a JSF or Spring frontend could have a dependency on the actual libraries that make up the application; this would give them the migrations and the actual data shape. But this means that bugfixes might not propagate properly; if I were to find a regression in the application, well, the https://api.bytecode.news domain is canonical, so I could fix it by rebuilding and redeploying. A downstream application that had access to the database might not include that regression; that means we have inconsistent deployments, and that is the same as a broken website, especially if the regression is an actual bug.
And that implies that I trust those authors, too: I probably would, or else I wouldn't bother deploying their domains, but even so! What if they do something that is incompatible, or insecure, for other aspects of the system? The system would still be broken.
So what then? I thought about providing a read-only user for the database - that way they could render directly, but updates would have to go through the REST endpoints. That might work - and it means that their application would have a little less dependency on the specific deployment in place. It's still a separation from "the ideal" but it might be the best of both worlds, except for the possibility of exposure of data they shouldn't; https://bytecode.news/ stores very little secure information (the users don't have passwords) but that doesn't mean no secure information.
Right now it'd be very difficult for an API that consumes REST information to get anything secure out of the system, because the REST interfaces don't expose it. But internally the system has to have a way to know how to log on to IRC, or discord, and the backend code has access to that information and someone deploying the backend as executable code might have access to that information and expose it inadvertently.
It's a difficult problem, and I'm not entirely sure how to solve it, outside of very carefully auditing any code that relies on the actual Kotlin code that comprises the system.