Future of Dgraph clients, e.g: dgo, in regards to GraphQL Dgraph

What is the future of Dgraph clients which are using grpc in regards to GraphQL Dgraph in v2?

For example, one problem is that, if we created a schema using GraphQL with the /admin/schema , we will have schema’s that are prefixed with their types. Thus it is handled differently, as they return different JSON fields, whether if we are querying using the dgo client and the /graphql endpoint.

There is also the @id directive to handle uniqeness in GraphQL Dgraph, and which I suspect there will be more features built on top of the GraphQL endpoint, causing feature disparity between GraphQL ± and GraphQL.

What is the recommended architecture if we are using GraphQL dgraph to a backend service?

They will continue to do what they already do.

If you are using GraphQL, stick to it and use GraphQL+- for special or internal cases (like querying through Ratel).

In fact, what is being done is to create ways for GraphQL to support functions that it does not support natively, which exists only in GraphQL+-. I believe that many of the functions that exist in GraphQL+- will never be part of GraphQL Specs. And everything that GraphQL Specs adds later will be easily supported in Dgraph.


Hmm okay…

One of the advantages of using a grpc connection was that we had one persistent connection that we could reuse in our backend service as opposed to creating a new HTTP connection every time with the current GraphQL solution. But I’m not sure if this drastically decreases performance anyway.

I’m currently looking to support the Dgman library to support GraphQL schema, which means we can’t base the implementation on dgo anymore.

Thanks @MichelDiz.

@michaelcompton what do you think about this? could Dgraph’s GraphQL support GRPC somehow?

There’s no technical reason why we can’t serve GraphQL over gRPC.

We’ve thrown the idea around a few times, but have no current plan to implement it.

If it’s something you really want, then please add a GitHub issue for it with a description of why and we’ll best be able to track the idea from there.