I believe there has been a lot of discussion about making GraphQL the standard language. Dgraph has put a lot of effort into this, whether or not the others can/will accept it will be up to them. Why don’t you just look on the positive side with how fast a graphql API can be fully generated to a done state with Dgraph. That is their strong point. There has been some discussion (either forum or github don’t remember where) about SPARQL but I think the direction Dgraph has chosen to take is the correct one. Give them some more time to make it better and let’s have this discussion again.
You have to remember how long Dgraph has been at this compared to their competition and any of the other Relational Databases. It would be interesting to look at MySQL or Postgres on their 2 year mark from conception and see what all features they were missing and bugs they still had to work out.
Here is this again:
“GraphQL is not a Graph DB query language — it’s a replacement for REST APIs." - @mrjn Building a Native GraphQL Database: Challenges, Learnings and Future - Dgraph Blog
The goal here is not just to make another database which serves an API endpoint which most of the other competition is doing. The goal is to remove a whole layer from the stack where the database and API is one in the same.
You said yourself,
and I agree, it would be annoying, but if GraphQL becomes the standard then the same schema (types, interfaces, definitions, queries, authorization rules, custom directives, etc) would simply work across every GraphQL API without changing anything at all!
And let’s face it, GraphQL is easier to understand and work with for beginners compared to any of the other query languages for graph databases.