I’m not saying that they break GraphQL specs but @auth contains quite a bit of business logic which should be handled by the server and not be applied to the schema directly. However, I’ve also said that I do not mind this approach as long as it does not go crazy.
I did not say that every user prioritises GraphQL but I’m almost certain that most users start using Dgraph because there is a schema only approach. Moreover, as this resembles basically Dgraph’s USP. The very first headline on digraph.io literally claims
Dgraph is the only native GraphQL database with a graph backend.
Although, I also basically only use DQL in my custom resolvers.
No one should choose between one or the other and thus interoperability between, in Dgraph’s case, DQL and GraphQL is even more important! In my opinion Dgraph is always GraphQL first and DQL should only be used when you are forced to exend the core business logic. However, I guess there could be cases where you build your own layer on top of DQL and use something else than GraphQL as query language.
I do not agree. It has nothing to do with holes in the GraphQL layer. I would even advocate NOT to extend the complexity of the current GraphQL since you would put more and more business logic in the schema. At one point you might find yourself having an @execute directive, where you run command blocks - again, I don’t think that this should be part of the GraphQL schema. I already have such complex @auth rules which I would love to tackle properly with a programming language rather than query logic.
Again, I’m not saying that it is everyone but certainly most people are hooked by the GraphQl part. However, since your client builds his own GraphQL layer, he is also somehow interested in the GraphQL part and the fact that DQL is similar, will certainly help. I think this is actually a perfect example for the necessity of a better DQL ←→ GraphQL interoperability!
No, this is simply wrong. An API is much more than a query language like GraphQL. GraphQL by itself cannot and never will be able to provide (programmable) mechanisms connect to services. But read for yourself, graphql.org has it as it’s H1 header
A query language for your API