Following Anthony, GraphQL is like that for consistency/predictability and security. We cannot require an API language to do the work of a DB language. I think the custom query solves part of this problem. It’s basically what other DBs do when they add GraphQL to their code base in some way. However, there is still a lot that can be done under the spec.
Nope, GraphQL foundation has total control of the Spec now.
There are profound changes to ask. That’s too much pretentious for us to request. We should work for now with what we have.
The logic behind GraphQL is to build your own GraphQL server by doing the whole business logic in the backend. I can’t imagine Dgraph predicting every possible means of business logic and supporting them all out of the blue. Or do something general. I think a pretty good part of the logic will stay with the DQL, lambdas and so on. Which it doesn’t mean we won’t fix or add new things to prevent the user from having so much work with the business logic.
I think you were covered by the spec, cuz no one can do anything out of the spec. In your backend, to resolve the query you can do anything you want. In Dgraph is different cuz everything is written in stone. The only logical freedom to solve a query is using Custom and so on.