Hi, just realized in the GraphQL Example page, there is a @id directive in the GraphQL schema.
What is the equivalent of the @id directive, to ensure uniqueness in a field, in GraphQL±?
There isn’t one. You have to ensure uniqueness with code. See: https://docs.dgraph.io/howto/#upserts and https://docs.dgraph.io/mutations/#upsert-block
Hmm ok, I figured. Thanks.
So what is the future of the grpc clients in regards to GraphQL Dgraph? Will we have to use the HTTP GraphQL endpoints to use any new features only provided by the GraphQL endpoints?
Hi,
Just wondering what you mean for GraphQL over Grpc. Do you mean the Dgraph clients - e.g. Dgo? And what sort of feature are you thinking - same sort of interaction as currently happens in the client, but just that it’s a GraphQL query string for example?
Yes, what I meant was the Dgraph clients, e.g: Dgo.
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.
So what is the future of Dgraph clients which are using grpc?
What is the recommended architecture if we are using GraphQL dgraph to a backend service?
Hi,
I added a note to your other question about grpc.
There’s nothing to stop you having both dgo and /graphql working together at once. Indeed that’s what some of our users want GraphQL for → to expose a GraphQL view over a graph where other processes are adding and mutating data.
There’s also no need to have different json fields. You can use aliases as a way of mapping internal values to your types, but also, you can map the GraphQL however you like to internal edge names, so you can have the dgo and GraphQL seeing the same names: see here.