How can one maintain in sync the application database with the permissions database?. Suppose there is a project which uses a postgres database and a spiceDB (backed by a separate database).
This project is a "github clone" and a user has decided to delete a repository with all of its related objects. In postgres these related objects delete automatically in cascade. How can I do the same in SpiceDB to avoid leaving garbage tuples behind?
There are a variety of synchronization methods, and the choice of which is very application specific.
The simplest choice to get started with is to add it directly to your application logic. The main pro of this solution is that you can directly handle the semantics of when and how to add/remove permissions. For example, it's sometimes safe and idempotent to write permissions for data that may fail to commit, because permissions for the data will never be queried in the future. You can also directly control the management of ZedTokens and effectively eliminate the new enemy problem[0]. As far as I know, this is how Zanzibar is used within Google.
Solutions which tail a primary source of truth, such as the database logs, kafka topic, event queue, etc. may perform better in some applications where eventual consistency on permissions is ok. With these systems you are adding some delay in between writing the data and the permissions, which can open you up to new enemy or require UX compensation like adding data on the client side and hoping the permissions replicate before they are ever queried for real.
We will work to write a guide that talks about some of these architectures and their pros and cons.
You are effectively "registering" the permissions on a separate service, so you need to handle updating those accordingly.
In the case of deletions, for example, you would need to track what entities you are deleting and call the service to update/delete the related permissions.
You could do this with some worker subscribing to postgres NOTIFY if you wanted to keep it closer to your DB layer (but that is async, and you may end up losing changes in the case of worker outages), or you could do it in your app where you would have more control over the transaction.
EDIT: I'm not associated with SpiceDB/Authzed in any way.
Sounds like a great use case for log-based change data capture actually. That way, you won't miss any updates also in case of outages, network issues, etc. Once everything is up and running again, such pipeline would resume from where it left off before. Plus, (unlike anything based on application-side triggers) no need to modify your app or the risk of missing changes e.g. done directly on the DB via SQL.
Disclaimer: I work on Debezium, an open-source CDC solution
Yes, exactly. Debezium (debezium.io) provides log-based CDC for a variety of databases, exposing a unified event format as much as possible. It can be used with Kafka (Connect), but also stand-alone or as a library embedded into your app.
This project is a "github clone" and a user has decided to delete a repository with all of its related objects. In postgres these related objects delete automatically in cascade. How can I do the same in SpiceDB to avoid leaving garbage tuples behind?