I recently discovered Dgraph and am quite impressed with its capabilities. I would like to use Dgraph as the primary store behind a regular golang GraphQL server, which will be responsible for implementing access control, session management and things like Relay edges and connections. As I understand it, this implies steps along these lines:
Parse the incoming GraphQL query from the client.
Traverse the parsed query and incrementally build up a Dgraph query.
Send the consolidated query to Dgraph and get the response.
Traverse the Dgraqph response and translate it into the desired shape (e.g., with Relay connections).
Send the translated result back to the GraphQL client.
Does this sound like the right idea? Has anyone done something like this who can recommend one or two golang libraries that will be helpful here? The most popular golang GraphQL library, GitHub - graphql-go/graphql: An implementation of GraphQL for Go / Golang, seems to be doing to much and requires synchronous resolution at each field in the query.
What’s your strategy for translating the query coming in from the client to the GraphQL±? Are you using graphql-js’s parse function and then walking the document? Or are you using a higher-level library to help out with this?
Actually I’m just using the Dgraph-JS client in my Resolvers.
In the NodeJS application I create my schema and resolvers according to queries and mutations for Dgraph. Client JS solves everything for me. I do not need to do anything too much.
On the query, I use the query directly. And I usually use graphql variables. The templating from ES5 helps a lot. In query building.
Does that approach result in one Dgraph query per field, or does the NodeJS GraphQL library you’re using somehow batch up the individual Dgraph fragments into a single query and pull apart the response once it’s received?
The Dgraph-JS is the (lib) client I use. Through it I send raw queries and the mutations in RDF.
At first it happens like this:
Apollo Client <=> GraphQL Server in NodeJS <=> Dgraph-JS <=> Dgraph stack
The Dgraph sends the result (data) the Server solves this data (be it query or mutation). And Apollo consolidates everything for the customer. It is very automatic and direct everything.
GraphQL fragments can be used in the Apollo client normally.
In my case I use the ES5 Template. With it I can reduce multiple queries in generic queries. I create fragments and create a logic that adds fragments or not depending on my need. And sometimes I have to create a logic for some function that does not exist in GraphQL.
Mutations I have one for each type of node. Mutations do not have much to do.
Ok, that’s what I was thinking. My initial hope was that since Dgraph can provide arbitrary results via a single network roundtrip, that someone might have solved the problem of consolidating the requests made by the NodeJS (or Golang) GraphQL server resolvers into a single Dgraph query, and then rehydrate the result from the other direction, rather than issuing multiple network requests to Dgraph. Here is an example of the same idea with SQL:
This library is similar in spirit to Facebook’s dataloader, but it batches SQL queries instead of caching fetches of individual keys. I was wondering whether someone had solved a similar problem for Dgraph fragments (in contrast to SQL queries).
This might be premature optimization, but since part of Dgraph’s appeal is its very fast response times, and network roundtrips are expensive, it seems like something worth looking into.
If they add the Cypher in the J-monster would be perfect for the Dgraph in JS applications. Now it would have to build something similar for other languages. like Go.
Now, in that case I think I would have to start from a third party the initiative to build something like J-monster for Graphql to Dgraph. For this idea is not part of Dgraph’s proposition i think. Dgraph is only inspired by GraphQL. Just seeing with @mrjn about that.
In the Dgraph roadmap there are intentions to support the GraphQL standard as a whole, but I do not know if it will be compatible with GraphQL clients and other tools. Let’s see.
And I do not know a lib equivalent to Join-monster for golang.
Thank you @MichelDiz. I do use GoLang for my backend and I’m quite new to that language so I guess I’ll have to wait and hope for someone to implement such a lib. Maybe I’ll do it myself when I’ll be more comfortable with GoLang and DGraph.
I think even if Dgraph fully supported GraphQL, there would still be a need to put a gateway in front of it, to enforce things like access control, to facilitate application-specific business logic, and possibly to aggregate other sources into the API surface. It seems like Dgraph is best treated like Redis, Memcache or Postgres, in the sense that you wouldn’t want to connect a client directly to it.
In light of that, there will still be the challenge and need of translating a GraphQL request to another GraphQL request without breaking the second request up into a number of individual network calls. I’ve started work on a rudimentary Golang wrapper around libgraphqlparser, a c++ library that allows you to use the visitor pattern, but work on it is intermittent, and it will be a long time before it is ready for people to actually use.
Well, I’m not exactly sure how the Dgraph support for GraphQL will be.
But we have the following hypotheses.
If the support is only in the language. There would indeed be a need to create a “bridge”. But that would be the standard of any DB technically speaking. All DBs you need to connect to a GgraphQL instance via resolvers.
If the support is “simulated”. In the sense that there is complete language support and Dgraph simulates a GraphQL schema and all its nuances. So there would be no issues with clients that only recognize GraphQL. Things like Apollo GraphQL would accept connecting to Dgraph simulating a GraphQL service.
You can simply create a gateway (as we are discussing from the beginning) where it does Dgraph stitch with simulated GraphQL service and you can still use other DBs and solutions together.
but as I said, I do not know if there will be a simulation of a GraphQL service. But this is not a problem as I see it, today we can do this without even needing to support GraphQL lang.
