In OpenFGA/Auth0 FGA, the “relationship graph” is not usually a separate graph database or a pile of downstream service calls. It’s an implicit graph whose edges are the relationship tuples you’ve stored, interpreted through the authorization model (the DSL that says how one relation implies another, how to follow parents, groups, etc.).
These are persisted in the OpenFGA datastore (commonly Postgres).
What “traversal” actually does at runtime
A Check(user=X, relation=R, object=Y) request is evaluated by resolving the model for (Y#R) and reading whatever tuples are needed to prove/disprove membership.
Traversal becomes painful when checks cause High fan-out (e.g., a document inherits viewers from a folder, that folder has 50 groups, each group contains groups…)
or like Deep nesting (group-of-group chains)
That’s exactly the niche where smarter planning/strategy selection helps.
Do checks require “a bunch of API calls to downstream services”?
Normally, no. OpenFGA/Auth0 FGA doesn’t need to call your microservices to traverse your domain graph. The check is decided from:
- the authorization model, and
- tuples in the OpenFGA store,
- plus any contextual tuples you included in the request (ephemeral edges that behave as-if written, but aren’t persisted).
I really respect OpenFGA & team behind it, I used it in multiple projects and it completely eliminate the AuthZ from our code.
But it always had this issue with Admin management, It is hard for Admins to understand and maintain.
That’s why I created an Admin UI for OpenFGA, The main goal is that the UI is Dynamic and it changes as per your OpenFGA Model, Then you can Easily Add users
I built this because my team was constantly struggling with managing permissions in our applications. we tried building admin UIs multiple times, but every time the OpenFGA model changed, we had to rework the UI layer to match it one way or another.
So mainly the UI understand your OpenFGA schema and automatically renders the management interface based on the entities and relationships defined in your model.
We actually use dapr which provides abstraction layer over all of those things including
State management, Pub/sub, etc..
So it’s really easy to switch between them without changing the code at all.
It’s very fast usually I struggle with backup tools on windows clients.
And it ticks all my needs. deduplication, End-to-End Encryption, incremental Snapshots with error Correction if any, mounting snapshots as a drive and using it normally or to restore specific files/folders, Caching.
The only thing that could be better is the GUI but it works.
zfs is not an option with windows clients and even most linux clients. Also finding these set of features is really scarce not sure why !
I am using zfs on my server though!
Guys on my team struggle with Apex daily since we've started using it, which has lead to me look for a better, FOSS alternative. This looks like it might be the one
This is one of the moments that i read an article and say to myself: “Those stuff needs a smarter programmer than i am”
I will try to watch the video, hopefully it is simpler to understand !
I've thought that many times and always been wrong. At the end of the day, code is just code. After you take the time to understand the environment it's running in, it's not that much different than anything else you could write.
Creating BPF in the first place took a lot of cleverness. Figuring out how to fit it into a massive infrastructure at a place like Facebook took a lot of cleverness. But most of the people actually working on the implementations are just normal software engineers.
There is lots of code that is difficult to understand, for anyone.
What about code that proves a complex, many page mathematical theorem?
What about code that does complex and very math heavy things like GCM encryption modes, or statistical compression via prediction by partial matching and arithmetic coding?
Just reading the code isn't always enough, plenty of complicated code requires understanding of concepts far outside what you could hope to fit in a comment.
What the graph “is” in a typical deployment
Edges = tuples like: document:1#viewer@user:anne document:1#viewer@group:eng#member document:1#parent@folder:A
These are persisted in the OpenFGA datastore (commonly Postgres).
What “traversal” actually does at runtime
A Check(user=X, relation=R, object=Y) request is evaluated by resolving the model for (Y#R) and reading whatever tuples are needed to prove/disprove membership.
Traversal becomes painful when checks cause High fan-out (e.g., a document inherits viewers from a folder, that folder has 50 groups, each group contains groups…) or like Deep nesting (group-of-group chains)
That’s exactly the niche where smarter planning/strategy selection helps.
Do checks require “a bunch of API calls to downstream services”?
Normally, no. OpenFGA/Auth0 FGA doesn’t need to call your microservices to traverse your domain graph. The check is decided from: - the authorization model, and - tuples in the OpenFGA store, - plus any contextual tuples you included in the request (ephemeral edges that behave as-if written, but aren’t persisted).
reply