How to design GraphQL queries efficiently for nested data in Dgraph?

Hello

I am building an app with Dgraph as the backend & noticed that my GraphQL queries become very slow when I fetch deeply nested data. :slightly_smiling_face: For eg; retrieving a user along with all their posts, comments & likes in one query looks elegant, but the response time increases a lot as the dataset grows. In some cases, the query even times out.:innocent:

I have read that GraphQL is powerful for hierarchical data but I am unsure how to balance query depth with performance in Dgraph. :slightly_smiling_face: Should I be breaking down large queries into smaller ones / is there a way to optimize schema design to handle these nested relationships more efficiently? :thinking:

I am also not sure if caching can help in this case, since the data changes frequently.

Has anyone faced similar issues with nested queries in production?:thinking: Checked GitHub - dgraph-io/dgraph-docs: A native GraphQL Database with a graph backend documentation guide for reference. Sometimes I feel that learning GraphQL concepts is similar to what is javascript , because both require understanding the fundamentals before building real applications.:thinking:

I would appreciate advice on whether to restructure my schema, use query batching / apply specific Dgraph features to keep performance stable as data grows.:slightly_smiling_face:

Thank you !!:slightly_smiling_face:

Hi @sopelos, welcome to the community….

Changing your schema may help. Also, the use of inverse edges can speed up queries by “working backwards” from a smaller set of matched predicates.

However, in most of the production graphs I’ve been involved in, the need to use Dgraph’s core query language, DQL, becomes a necessity for performance. This doesn’t mean you have to give up your GraphQL schema and generated endpoints. Your SDL types and predicates are represented internally via DQL, which makes them accessible via DQL.