First of all, thanks for all the answers.
I guess I’m well aware about the difference of DQL and GraphQL. What I’m on about here is that it might be a bit confusing for new users when the documentation shows DQL mutations, written in JSON, which are based on a DQL schema only. I believe that most people (including me) are choosing Dgraph because of its GraphQL abilities, not the certainly powerful DQL query language.
I have to admit that, even though I was aware of a DQL schema, and that one gets auto-generated when deploying a GraphQL schema, I somehow did not see it as two separate things. This might have to do with how Dgraph blurs the difference between a Query language and a server which understands the query language and reacts according to it. Therefore, I have to slightly disagree with @amaster507 when he states that GraphQL is an API - there is a GraphQL API but GraphQL should always be understood as the layer between the requesting and the responding service. Dgraph kind of breaks this doctrine by adding a certain set of business logic to the schema itself where it usually does not belong (
I think Dgraph does a pretty good job here and it clearly shows that their approach is sophisticated enough to cover most of the business logic without writing tons of of code, setting up services, etc - this at least is true for most of our use cases. However, the missing, let’s say 10%, must usually be covered by writing custom resolvers or webhooks. And in my opinion, this is where you can’t really avoid DQL anymore. It’s just so much more powerful and lets you write safer and cleaner resolvers.
This is where it gets a bit complicated. You making a GraphQL request, process data with DQL in a custom resolver and (in most cases) must return valid GraphQL again. In our case this led to the development of quite a bit of tooling to deal with eg. the translation from GraphQL to DQL and vice versa, the parsing of the actual type from the
dgraph.type array, identifying predicates which are from interfaces and thus require the correct predicate definition, etc.
Obviously, it could be the case that I simply do not know enough DQL or misinterpreted concepts and best practises.
Nonetheless, for these use-cases it would be nice if there would be eg:
draph.interfaces array, which shows the interfaces which are implemented into a node
- a flag for the DQL endpoint or a parameter for
dql.query (inside resolvers) to get a valid GraphQL response from a DQL request. I assume something like this already exists since DQL is running under the hood.
- a DQL translation of the request body would also be nice
To summarise: I do not think Dgraph users should have to decide between using GraphQL and DQL. Most users will most certainly run into problems which they cannot tackle or getting overwhelmingly complicated when done using GraphQL only.
@Raphael the docs do not show this specific example but one which is quite similar:
Thanks for being on one page with me when it comes to GraphQL and DQL interoperability! As already mentioned, we do have quite a bit of tooling in place which, if of any help, we’d be happy to share.
@MichelDiz thanks for clarifying that not JSON nor RDF is DQL.
@amaster507 kudos for writing this article! However, as already mentioned above, I’m not 100% agreeing with you here. GraphQL is not an API and nor should potential users decide if they want to use DQL or GraphQL. I think GraphQL should always be the main focus and I see DQL more in the realms of “backend operations”, meaning custom resolvers, etc.