This message was deleted.

There are multiple ways to go about this. But in general you’d be using Zanzibar as a datastore, and as you say use a data-fetcher to load data or subsets of data from into OPA. At Permit we combine that with a Go plugin for OPA that optimizes the navigation on the graph subset downloaded from the Zanzibar system. Note that non critical path queries like reverse indices (Who can do x, as opposed to can Y do x) could/should still be executed against the top full Zanzibar solution

So, if I understand correctly, OPA downloads relation tuples from Zanzibar datastore and evaluate the relation locally, instead of making an evaluation request to Zanzibar

Yes, that would be my recommendation, Solving latency, availability, and coupling issues

Any chance the Zanzibar plugin is opensource? Or if there is an article/blog post that I can learn more about it? Thanks!

We are thinking about open-sourcing it (CC: @Asaf Cohen, @Omer Zuarets, @Shaul Kremer) But haven’t yet - also it’s more of a ReBAC graph plugin than a Zanzibar plugin but I guess that’s almost semantics in this case

Thank you!!