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?
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.
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.
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.