Hi Guys. We have a schema design question, we have two options and we are interested in the benefits and side effect of each option. The problem is a simple one: we have a service whitelist that gives permissions to endpoints. This is very close to your "Simple Role Based Access Control" example. We have 100+ services and 10000+ endpoints Option 1: one service definition, endpoints such

users_get

are encoded as relations. > definition identity/client {} > definition service { > relation everything: identity/client > relation r_users_get: identity/client > relation r_users_update: identity/client > relation r_users_delete: identity/client > relation r_users_post: identity/client > relation r_users_list: identity/client > permission users_get = r_users_get + everything > permission users_update = r_users_update + everything > permission users_delete = r_users_delete + everything > permission users_post = r_users_post + everything > permission users_list = r_users_list + everything > } Option 2: two definitions one for the service and another for the endpoint. > definition client { > } > definition service { > relation member: client > relation whitelist: service | client > permission access = whitelist + whitelist -> member > } > definition endpoint { > relation parent: service > relation whitelist: service | client > permission access = parent -> access + whitelist + whitelist -> member > } Option 1 requires changing the schema through

writeSchema

. We are thinking of doing this dynamically without schema owner intervention whenever a new API is declared through an internal dev portal. We also think this will be faster and store less data but we have uncomfortable with the dynamic writeSchema idea especially since we have been working with a hardcoded schema so far. Option 2 is more flexible by coding endpoints as a definition. This comes with the benefit of not exposing the writeSchema in any way.