Confirm or deny basic understanding of Dgraph (especially GraphQL / DQL)

Users Dgraph
1

I’ve done a number of tutorials, but it is still a bit unclear to me what is the best practice regarding GraphQL and DQL.

This blog post is helpful (GraphQL vs DQL - Dgraph Blog) but it is rather vague around the specific limitations of GraphQL:

With this knowledge, it is easy to understand that anything that can be done in GraphQL can be done in DQL, but the opposite is not necessarily true. Some queries and mutations are possible in DQL that are simply not possible in GraphQL, mainly due to the restriction of the GraphQL specification itself being a strictly typed query language, and DQL being a loosely typed graph query language that can even work without a predefined schema.

It further suggests that DQL features go beyond the normal use cases of a front-end applications (which can be debated?) and that a primary use case for DQL is to have a secure internal API (which I wouldn’t argue against.).

GraphQL provides clients with a strictly controlled query and mutation endpoint that developers can tightly control while DQL provides developers with a more flexible graph query language to control their data in ways outside of the normal use cases of front-end applications.

but the developer can have an administration site that he alone has access to and can add in other related fields and data objects at will without being constrained by GraphQL syntax specifications.

Seeing this from the perspective of building a complex frontend app, my broad concern is that GraphQL schema development will become a complex abstraction over DQL schema when in fact our front-end application has quite extensive needs. Furthermore I see a risk in confounding frontend developers if it’s not clear from the outset which APIs to rely on as we build incrementally powerful helpers and fragments.

To give some context, in our use case we have about 1000 Types with various inverse relationships, language strings and so forth. Our frontend will depend on both simple and very complex queries against these 10M+ triples and I would much appreciate if you can confirm/deny/add guidance on the below 4 questions:

Confirm or deny 1
When running dgraph.Operation().setSchema() I was a bit surprised to not see any GraphQL schema generated, but I guess the default here is DQL … But my understanding is that I should be able to update the GraphQL schema and the DQL will be generated under the hood?

Confirm or deny 2
Will we then also be able to access ANY (!) advanced DQL functions (such as GroupBy, recursion) via Custom DQL? https://dgraph.io/docs/graphql/custom/dql/.

Confirm or deny 3
If we regularly use advanced DQL features like language fallbacks, aggregations and so forth, would it make sense (and is it even possible?) to do that via the GraphQL or would we be better of building on top of DQL only?

Confirm or deny 4
If we use DQL for querying (bypassing the GraphQL), would it still make sense for us to always update the schema via GraphQL (to at least get a standard GraphQL introspection experience for less complex needs)? Or does that limit our expressivity and we should go directly for DQL also schema-wise?

Thank you for any help!

1 Like
2

1: yes
2: yes
3: depends, Dgraph’s GraphQL gets rewritten into DQL in the core. But if you want more control you could write your own GraphQL layer using both DQL and GraphQL in resolvers
4: depends, if you know you will never use the generated GraphQL API then it would not be used, but having it and not using it does not create much of any overhead for the most part.

3

Thank you!

At first glance it seems a bit contradictory with the answers to question 2 and 3 – i.e. on the one hand we get all the powers of DQL via GraphQL, on the other hand you’re indicating that we could get more control by customizing how the GraphQL layer taps into the DQL features. But I think I follow.

But just to go back to question 2 for a second: Are you then saying that the GraphQL layer will be sufficient for us to create a complex frontend that needs access to language fallbacks, recursion, aggregation operations, inverses and what not that currently is mostly documented on the DQL side of things? Or does this immediately call for us to adapt the GraphQL layer to wrap around some DQL features in a more customized fashion.

It would be very helpful with an example that:
a) Shows how to import GraphQL Type that makes use of many complex predicates and features.
b) Shows how to query that Type via GraphQL and what is available out of the box versus what would be unnecessarily complex to do via the default GraphQL layer alone.

If there’s an elaborate example like this somewhere it’s be great if you can point me to it. Alternatively I can try to create one.

Thanks again!

4

I have an elaborate example with over a hundred types plus auth rules and deep relationships. But it is too big to post here and I am not comfortably just posting it publicly to share my auth rules with the world.

I may have some time this evening or tomorrow afternoon if you want to PM me and we could do a zoom meetup or something to answer more of your questions.

Every use case is unique so maybe understanding what you are trying to do will help understand the context of your questions.

Of course we can continue here on this post as well if you would rather that too.

1 Like