I think now that we support GraphQL official spec, the naming GraphQL± can get confusing. Instead, we can rename it to either DgraphQL or DQL. Make it clear that it is a fork of GraphQL.
What do you guys think should be the name of Dgraph’s Query Language?
0 voters
After working with it some more and after the initial understanding that you support both and which one to use where I like the term graphql± and I read it now as “graphql more or less” which flows together well with the history of where it came from and where it is headed supporting a true graphql endpoint.
I look forward to the day when grqphql makes advances enough where it can become the standard de facto. I think it is close but still missing some of the advance usage such as var blocks and upserts. That would be awesome to bring into native graphql (probably with more directives)
I like DQL! You have like SQL for example, and you have FQL (FaunaDB), etc. It’s super simple and most importantly has the “D” for Dgraph 
This rolls off the tongue!
FWIW, I really like the name GraphQL±, and the name immediately struck me as being a flavour of GraphQL. What I like about it:
What I don’t like about it:
GraphQL± on any major search engine (I tried Google, DuckDuckGo, Bing, Yahoo) yields nothing related to Dgraph. Searching for GraphQL+- will always return results from graphql.org before dgraph.io.GraphQL± and GraphQL+-).The trade-off between familiarity and searchability is real, and changing a name always causes friction. Overall, if we were to take the plunge, I’d say we should go with “DgraphQL”.
As a GraphQL database, shouldn’t Dgraph just support standard GraphQL and extensions to it (GraphQL++/…) that fully utilize the underlying capabilities of a distributed graph database? I think having two different related query languages for a DB would be confusing with any name.
Highly agree with you. Maybe the extra enhancements which GraphQL± brings in should be as directives to GraphQL itself. That’s how apollo is adding more with Federation (https://www.apollographql.com/docs/apollo-server/federation/introduction/).
Maybe its better to stick to the GraphQL spec but support directives allowing developers to just go with 1 query language also reducing your efforts maintaining it.
If we can do that, it would be great. But, there are a bunch of open ended questions there:
@mrjn Really like this thread: GraphQL+- -> Spec Compliant GraphQL
Maybe the focus should go more towards it and trying to answer those questions rather than making the users learn another language. That way you will have more adoption as well along with a huge ecosystem of already built tools.
Ultimately if you see it, GraphQL is all about expressing data. So, for instance as described in the linked post, rather than writing "rating@en": "tastes good" it is may be better to opt for something like:
"rating": {
"en":"tastes good"
}
which is spec compliant. Maybe something similar can be done for all the issues mentioned in the post.
Also, maybe you can look at others like Hasura for some inspiration. Eg. This is a proposal for similar language tags: https://github.com/hasura/graphql-engine/issues/5215#issue-645944604 which is compliant with GraphQL.
PS: I have added my suggestiions to the linked thread.
I have to say that Dgraph± seems to be a really problematic name because of the fact that there is no way to know how to pronounce it ( I always thought “GraphQL plus minus” which really isn’t great ). Adding to that is the fact that most people wouldn’t even know how to type it. I can type the ± on a Linux computer using the composer key, but I don’t know how you type it on a Windows computer without opening up the character map, searching for it, and copying it to the clipboard from there.
I think the best option above is DQL because it most clearly points out what it is. It’s the Dgraph Query Language, even if it is very close to GraphQL, you don’t want people getting mix up with it and GraphQL. Having the names too similar to each other seems like it would make it easier to get one mixed up with the other, and like @ajeet said, it causes problems with SEO when the only difference is the ± character.
I do undertand the origin of GraphQL± and it makes sense, but it just doesn’t work out so nicely in practice I think.
I think having it on the Dgraph website that DQL is very close to GraphQL with some added features and some removed features, just like it is portrayed on the website today, is more than enough for me to get a quick understanding of its similarity to GraphQL, without having to name it GraphQL±.