https://authzed.com logo
#spicedb
Title
# spicedb
w

williamdclt

02/25/2022, 4:25 PM
Mmmmh I see, thank you @User! But if I'm understanding correctly that would mean that, when writing my relationships, I need to write both: -
flag:new_admin_dashboard#flag_new_admin_dashboard@organization:my_org
-
organization:my_org#organization@flag:new_admin_dashboard
That's redundant, which makes me sad 😢 For reference, our current system which works very very similarly to SpiceDB (SPARQL-based, also Zanzibar-inspired) is based on checking that a set of relationships exist. So our policy would look something like (this is a made-up policy format):
Copy code
permission view_new_admin_dashboard: flag:new_admin_dashboard#flag_enabled@organization:{subject} AND user:{object}#admin@organization:{subject}
This does not have the problem of storing duplicated relations, nor do I need the awkward
flag_new_admin_dashboard
relation: I can hardcode a specific flag directly in my policy and have a generic
flag_enabled
relation. I'm super keen to use SpiceDB as it does everything we had to implement ourselves, and very likely it does better! But being able to easily handle feature-flags (and similar things like user settings) is super important for us: is there any other approach I could explore?