After developing an app for approximately a year with dgraph as our backend, we noticed that although it is nice that everyone can write their own queries when needed with arbitrary depth and complexity, it is very hard to estimate how efficient the query will be in the end.
Possible options that might make queries exponentially more expensive than it might look like:
- use of @cascade due to lack of child-property filtering
- use of pagination: dgraph seems to query the full data and only applies pagination afterwards
- use of auth rules: dgraph seems to run multiple queries to the database to enforce auth rules
It would be great if dgraph could give some kind of complexity estimates when writing GraphQL queries. So the frontend-dev could easily check if his/her query is behaving “nice”.
This is especially important because in a dev environment you usually don’t have a huge local database. So all queries might complete in milliseconds. There is no way to test the real latency of a query unless you execute is directly on the live system.
We had an example where the local query was finished in 20ms and on our live system 20seconds