Inheritance: Superclass Subclass hierarchy in Types (nodes)

[amaster507 (Anthony Master)]

The short answer to your question is, Dgraph does support GraphQL type inheritance natively in its GraphQL API endpoint.

To get more technical about how it does this, and some of the caveats of it keep reading…

Dgraph’s GraphQL API is a subset of functions in the core of Dgraph rewriting requests into DQL (Dgraph Query Language). DQL was developed to be similar to GraphQL syntax but deviated with functionality so it could be used as an actual Database Query Language. More about this from these official doc pages:

GraphQL - DQL interoperability - GraphQL dql

To explain this a little more in detail let’s use an example:

interface PhysicalIndividual {
  id: ID!
  dateOfBirth: DateTime!
}
interface Person implements PhysicalIndividual {
  name: String! @search
}
interface Author implements Person {
  authored: [Book] @hasInverse(field: "authors")
}
type Book {
  id: ID!
  name: String! @search
  authors: [Author] @hasInverse(field: "authored")
}

so this ^ is GraphQL interface inheritance which you were referring to, and if you pass this GraphQL schema into Dgraph then it will generate the API and DQL schema to support this inheritance as you would expect it to work.

Now how this looks in the DQL schema and type system is a little more complicated or simple depending on how you look at it. Dgraph’s DQL type system does not support what GraphQL terms an interface but it does support nodes with multiple types. So this in DQL schema would look something like:

type PhysicalIndividual {
  PhysicalIndividual.dateOfBirth
}
type Person {
  Person.name
}
type Author {
  Author.authored
}
type Book {
  Book.name
  Book.authors
}
PhysicalIndividual.dateOfBirth: datetime .
Person.name: string @index(term) .
Author.authored: [uid] .
Book.name: string @index(term) .
Book.authors: [uid] .

Now a node that is a Author could look something like:

{
  "uid": "0x2a",
  "dgraph.type": ["Author", "Person", "PhysicalIndividual"],
  "PhysicalIndividual.dateOfBirth": "1564-04-01T00:00.000Z",
  "Person.name": "William Shakespeare",
  "Author.authored": [{ "uid": "0x2b", "Book.name": "Hamlet" }]
}

One of the problems with this, is that in DQL, there is no garentee that a node inherits the classes correctly. For example, you could have a node that has the types: ["Book","Person"] which doesn’t logically make sense, but the type system in DQL would allow it.

If you can only stay in Dgraph’s GraphQL API then you might be safe. Be sure to give a good look over:

The Good, The Bad, The Ugly - State of Dgraph

Talking with @gajanan (or @gajanansc) earlier today, He requested, I post a discuss topic summarizing a bunch of links for feature requests, current problems, ideas, suggestions, etc. The goal here is to be factual and technical. Oh and for those who may have not known before, @verneleem is also me If I have to do all of the raw data filtering, manipulation, and analytics in a client outside of the database, then why have the database at all? ^ Sometimes it seems right now that we h…

However if you when you need to use DQL, you will need to write a logical layer in your own custom API to make sure that types are inherited correctly, and that required fields are actually required. (DQL type system has no concept of required fields).

The examples above hinted at some of the manually conversions you will need to consider with GraphQL <> DQL interoperability with field renaming, etc. I also prefer using DQL’s @reverse directive with reverse fields by ~field over Dgraph’s GraphQL @hasInverse directive which creates bi directional edges and can get nasty quick if you don’t also manually manage these inverse edges with any DQL mutations you use.