I've been experimenting with a novel backend design concept where both the schema and authorization rules are expressed as data stored within the system itself. In this approach, data is represented as simple 'facts'—similar to a triple store—and queries are made by pattern matching those facts. Authorization is enforced using the same mechanism, which helps to streamline the process. The goal is to eliminate issues related to schema migrations as data models evolve and to do away with separate authorization logic written in backend code. This idea is loosely inspired by RDF/triple stores but is being implemented in a simplified manner on top of Postgres. I'm really curious to hear what everyone thinks about this approach!
3 Answers
Interesting concept! I do wonder about how you'd handle performance as your fact base expands. Pattern matching for every authorization check can get quite expensive without solid indexing. It sounds cool, but you might need careful schema design to keep things running smoothly.
This reminds me of the Entity-Attribute-Value (EAV) or triple-store pattern, which is like building Datomic on Postgres. It's a solid architectural choice with its perks, like schema flexibility and a cleaner auth model, but watch out for trade-offs like query performance and cognitive load for developers. Also, how will you manage changes in Fact structure over time? I’d love to know your indexing strategy!
I think this is a fascinating way to handle schema and authorization, pulling in ideas from Datomic and triple stores. One practical tip for documentation—if you're writing it in Markdown, consider using an HTML to Markdown converter like the one at Practical Web Tools to bring in content from web pages easily!
Related Questions
How To: Running Codex CLI on Windows with Azure OpenAI
Set Wordpress Featured Image Using Javascript
How To Fix PHP Random Being The Same
Why no WebP Support with Wordpress
Replace Wordpress Cron With Linux Cron
Customize Yoast Canonical URL Programmatically