The @auth directive is used in many GraphQL interfaces (neo4j, hasura, grafbase, etc, etc). Directives are not breaking any GraphQL specs.
It is also not true that everyone comes to Dgraph just for the GraphQL. The more and more I get into Dgraph, the more I appreciate DQL over GraphQL.
I do agree with you that GraphQL, literally short for Graph Query Language, is not just an API. Then again, is React a framework or a library?
Should Hasura users have to choose between GraphQL and SQL? Should neo4j users have to choose between GraphQL and Cypher?
They are two completely different things. The problem is that in this case DQL and GraphQL happened to be similar, so therefore more confusing. There are historical reasons for this I won’t get into, but it just happens to be similar for all intensive purposes. That doesn’t mean they should be considered the same thing.
As far as the schema, you should never touch the DQL Schema. Always let the GraphQL Schema generate this for you. You have one place. This would be the same for Prisma. You wouldn’t manually modify the SQL tables.
There is not direct way to translate DQL to GraphQL (not written) or GraphQL to DQL (generated, and unique to different @auth rules – could also be changed with a query planner one day).
What you’re really seeing is some holes in GraphQL. When nested filters, complex sorts, and more auth rules are added, you won’t need to worry about 95% of your custom dql problems.
J