Creating custom resolvers for Dgraph GraphQL

Users GraphQL
15

This is a bit of a synthetic example, but it captures the key features of what I’m trying to do…

For example, consider if I am modeling an issue tracking system…

type Issue {
  id: Int! @id
  summary: String!
  type: IssueType!
  description: String!
  status: Status!
  owner: User!
}

type Status {
  label: String!
  icon: String!
}

type IssueType {
  id: Int! @id
  category: String!
}

type Project {
  id: Int! @id
  issues: [Issue!]!
}

type User {
  name: String!
  avatar: String!
  email: String
}

The client has a particular view that wants to display all the issues in a specific project for which the issue type is of category “bug”. Note that there could be multiple issue types with that category, according to the user’s configuration.

As best I can tell, GraphQL doesn’t really define filtering in any useful sense, and Dgraph’s GraphQL bindings can really express that rich of a question (in fact, last I checked, even GraphQL± can’t handle that directly).

So, I can write my own custom resolver:

type Query {
  bugIssues: [Issue] @custom(http:{
    url: "http://192.168.1.1:9990/bugissues",
    method: "GET"
  })
}

Without knowing a priori what substructure of Issue the client is going to query on, that resolver has to return the entire reachable graph from Issues in order to let the client make interesting queries.

query {
  bugIssues {
    id
    summary
  }
}

and since I am pulling the real data from dgraph itself, those objects have to be fully expanded by Dgraph, back to my custom resolver, and then back to Dgraph itself in order for Dgraph’s GraphQL engine to pick out the one or two fields that the graphql client has requested.

What I imagined is that I could just return the uids of the Issue objects, then dgraph could expand those objects (including chasing down any requested relationships) with only the minimal amount of information going over the wire.

Here is an illustration of what I’m talking about:
image
the highlighted data has to be fully hydrated even if the information is not needed to perform the necessary calculations (“crazy join”) just so that Dgraph can get the data needed to satisfy the original client request, even though Dgraph already has the data

1 Like