This is sort of about both Dgraph and the GraphQL endpoint.
What would be nice: If Dgraph/GraphQL endpoint supported multiple labels on nodes.
Are there any other graph databases doing it? Something that was recently introduced in Neo4j was multiple labels on Nodes (I think 4.0?)
Why this is not nice currently: In my schema I have a generic Contact type which has a predicate isType which points to an enum. I divide Contacts by the type of contacts they are sometimes, but othertimes I want contacts no matter what type they are. A Contact can be a Person and another Contact can be a Business and another Contact can be a School. In order to do this now, I have to filter by the isType predicate. It would be nice to have separate queries for each isType inside of my Contact type.
How I foresee this: I think this is somewhat already handled by interfaces in a way but not completely. I think just a few small(?) changes would make it work though with interfaces.
- I have not experimented if setting a
<dgraph.type>predicate overrides a previous set instance or if it adds another triple without modifying the first. - Allow @auth directive on interfaces [This is my main purpose for needing multiple labels because I have too much logic in the @auth on my Contact type to handle each isType.]
- Allow types to implement interfaces with no subfields. I believe some implementations of interfaces need to be exact copies and not have any extra fields. Right now the following code throws an error when submitted for schema:
interface Contact {
id: ID!
name: String
}
type Person implements Contact {
}
But this would validate but have extra non-needed fields:
type Business implements Contact {
doNotUseThisField: Boolean
}
Furthermore, and I am sure it has been discussed and is probably what is holding back @auth on interfaces, is what exactly it would mean.
Some might expect an interface to provide a base @auth directive which applies to any implementation @auth directive while others might expect a separate isolated @auth directives so that one could for instance block the interface down to admins only but allow certain implementations for other validated users. This might call for another directive in the end. Maybe like @baseAuth vs. @auth.
- @baseAuth would only be acceptable on interfaces.
- @auth would also be acceptable on interfaces.
- @baseAuth would act like a base set of rules to apply under any implemented @auth directives.
- @auth directive on interfaces would only be used if the query was for the interface itself.
I have seen that Dgraph already builds queries and mutations for interfaces, so that part is already done. WooHoo! So this may already be somewhat supported hence the Does/Will title.