Hi folks 👋, been using spicedb for a few months now and love it. Curious to hear how the community/experts handle more "generic" resource types like user groups? Or if any good docs on this! At a super high level - my current design not only includes resources/relations that my apps own. But it also contains relations, reconciled from external sources of truth, that I do not own. That way I can use those (with reasonable lag boundaries) in my own permission check evaluations. Think of things like LDAP AD groups, or HRIS integrations like cost centers etc. There is of course distinction in specific domains but all of that complexity is mostly encapsulated in my reconciliation process. For the most part in my spicedb schema, all I care about is a way to model "buckets of users". Given that, currently I'm using a generic resource definition in my schema "user_group". That way I get a lot of flexibility for granting access to things ie. Give user access, give users part of this ad group access, etc. I wanted to avoid having to copy+paste the same resource definition and unioning the types in these checks, so the generic resource seemed like a good bet. However with the simpler schema comes more complexity elsewhere ie. looking up user groups of a particular type a user is a part of etc. Also not sure about performance etc. Right now, I'm using prefixes to help differentiate types ie. "ad-group:", "cost-center:" etc. which helps a bit but just seems a bit weird. It also makes the reconciliation process be much more careful/strict to not add/remove relations for user groups it shouldnt be "managing" etc.

yeah, i'm not sure that i have good/easy advice here. i think my impulse would be to be explicit rather than implicit here, because dealing with logic at the level of the key can be a pain in the butt. on the topic of repetition, have you seen the [partial syntax](https://authzed.com/docs/spicedb/modeling/composable-schemas#partials) that's a part of the composable schema system? it sounds like it'd let you define the set of relations once and then apply them to all of the different types in your system. having separate types also means that as you want to add more logic/permissions to one type you're not polluting the definition of another.

yeah, its generally preferable to be explicit here

Great, thank you both for the feedback! I think that lines up with my intuition as I've worked on this more. Seems like taking the burden of a bit more complex schema management/registration sounds worth it. For the usecases where I may want more flexible permissions ie. can give access based on ad groups, or cost centers, or state residents etc. Is there an obvious performance impact of doing a union of types there (w/ partials/duck typing)? Or would that be apples to apples (assuming same number of group types, relations etc) as one larger shared resource type?

there is some overhead in certain cases, because they are distinct queries