The vast majority of applications today share a simple architecture. You have your "app" which encodes a whole bunch of "business logic". Your users interact with your app, and then your app talks to your database to store data.
However, the database isn't just a dumb dump. It has all sorts of "constraints" for your data and it will happily throw your app's requests out if it doesn't respect them.
These constraints also encode your "business logic". Things like "every cohort must have a facilitator who must be a user in the system", or "every user must have a username and email". Where's the line between these constraints and the more procedural logic stored in your "app"?
I'm not sure! And the more I learn about databases the less I'm sure. Postgres in particular, one of the most popular open-source databases, is incredibly powerful. It can enforce permissions across every piece of data in your system, run code when things change, respond to requests directly from your users, and can even run javascript.
If you want, you can use the database as a platform for orchestrating your entire application.
This might feel anathema to some people. Honestly, it made me pretty uncomfortable for a while as well. The code that defines an app is static, and approachable. It lives in files in a simple, versioned directory. Code that lives in a database by comparision feels like its strewn through a dark forest.
This is more a result of the interface than the reality. The tools we have for navigating, exploring, and maintaining file based programs are far more developed than their database counter parts.
That doesn't mean that the database-as-application is a new idea though. Some programming languages arrived at a similar end-result from the other direction, making programs more like databases. With small-talk you could persist the entire state of your program and reload it at any time, making the whole thing look a lot like a database.
But, for many reasons, the pattern hasn't yet been widely adopted. But, I think it could be an extremely good fit for the applications of a personal database.
Their key property is fuzzy boundaries. With impersonal apps, each lives in it's own world and only permits you to connect it through few, carefully patrolled, and often heavily sanctioned, border checkpoints.
The personal apps I'm dreaming of have no such boundries. You can have a tool for managing your contacts that works on the same data as a tool for reminding you to check up on your friends, which works on the same data as a tool for keeping track of your work tasks.
When you have many different applications interacting with the same database it becomes increasingly difficult to maintain constraints across them. If you need to ensure that every time you update the name of a document it's changed everywhere you reference it, you can't depend on every application that can change the name remembering to do so. So, you move that logic into the database, to run everytime the name changes.
What does this look given our data model? Programs, things that implement logic, could be just entities in the database with special attributes. Then you need some rules for when they're run. A simple model here is that each program can listen for changes to specific parts of your database, either specific attributes, entities, or values.
Then when it's triggered a program could do different things. It could update some other data in your system. Or transform the change that was just made. Or interact with something outside of your database.
One of the really big advantages here is that tools for exploring your data can be come tools for exploring your programs. The ultimate vision is a single tool for interacting with all your data, mediated by programs you write to encode your own personal logic.
Okay! This concludes my foray into personal databases for now. But you know I'll be back. You can get a peek at the (unfinished) draft of my essay on the subject here. I'm calling it a night as it's 4AM, but overall, I'm feeling good about the direction it's going in.
My main goal is to explain the motivations for personal databases, the properties they should have, and an arcihtecture I think would achieve them. I think I'm currently focusing too heavily on the last one there, and should spend some more time on why they'll be useful and their salient aspects.
Thanks for reading! Looking forward to hopping into something new with you next week :D
subscribe for updates