GraphQL+- is now DQL - Dgraph Blog

Blog
1

Dgraph is the world's only native GraphQL database. We now have got fantastic GraphQL support and a serverless GraphQL platform, Slash GraphQL, all backed by an open source graph database. So, we're updating our naming a bit to help our growing user base to understand our products.

Dgraph's query language has always been GraphQL-like, but, in order to support the features to query a graph database we've extended and enhanced that langauge.

We called our graph query langauge GraphQL+-, which was born as a fork of GraphQL back in 2016 when we were asked to support features like Transactions, Upserts, Group By, Facets and others. These features are not possible natively with GraphQL. So, we took the GraphQL spec and modified it to make it a complete Graph query language.

Since then, a lot has changed, and we now also support GraphQL natively. You can read more about our journey with GraphQL in a previous blog.

That's meant we had two similarly named languages:

  • GraphQL : for building GraphQL apps, and
  • GraphQL+- : to serve deep graph queries for any sort of app.

Based on community feedback, we have decided to rename GraphQL+- to Dgraph Query Language (DQL). There are multiple reasons for this change. Firstly, a new user can often get confused between the two while asking questions or looking for answers. Secondly, GraphQL+- is not very search engine friendly, because a user would often be redirected to links belonging to GraphQL instead. It's also difficult to type, so we wanted to make it shorter and simpler. We even conducted a poll and 74% of our community voted for DQL.

Going forward, that means you can now look at Dgraph's supported query languages as follows:

  • DQL is a full featured graph query language. It features transactions, upserts, aggregation and everything we know about graphs, packing some power when you app needs it. We'll continue to build and maintain clients in Go, C#, Java, Javascript, Python and HTTP.
  • GraphQL is the GraphQL API for your app. It lands you right in the GraphQL ecosystem, let's you develop natively with GraphQL, and works with everything that speaks GraphQL.

Of course, you can use the two together in the one app so that your GraphQL app is backed by whatever graph power you need. That's the best of both worlds: the ease of building GraphQL apps with Slash GraphQL while knowing that if you need to dip deeply into your graph, DQL is there for you.

If you aren't already building apps with Dgraph or Slash GraphQL, you can learn more about it in our docs on Getting started with GraphQL, or Getting Started with DQL.

ReferencesTop image: NASA’s Space Launch System (SLS) rocket soars to space in this artist concept depicting the Block 1 crew vehicle configuration launching to space. SLS will be the most powerful and capable rocket ever built for deep space missions.
![](upload://pescRkJIf6UkMYPa5dq4svoeqlf.jpeg) Pawan Rawal, Author

After graduating from IIT Delhi in 2014, Pawan worked in various startups understanding how the web works. His interest in distributed systems and application of concepts in Computer Science to solve real world problems led him to Dgraph. In his free time, he likes to travel, do yoga, read and cook.

This is a companion discussion topic for the original entry at https://dgraph.io/blog/post/graphql+-to-dql/
2 Likes
2

Very nice explanation. I admit I was confused in the past because people still had been consistently calling it GraphQL+​-, which feels not wrong but not right either to me. This blog post has now further confirmed what the title says.

I would like to know your long-term decision regarding DQL and how it will take a step forward and hopefully become a global standard in graph database industry — particularly against Neo4j’s Cypher Query Language and their upcoming one: GQL. Would it be possible to have a collaboration with them? Would there be another language that is compatible with Dgraph but also refers to the way of openCypher/GQL? Or would Dgraph just stay focused with their current two languages: DQL as a specialized but isolated one and GraphQL as a traditional and universal one?

I guess both these fundamentally distinct languages (GQL and DQL) living together would be possible, but the thing is Neo4j and the GQL community seem to be trying their best to make GQL as truly a global standard in the upcoming majority of graph databases, which might hurt the popularity of DQL and GraphQL at some point in the future.

I truly hope the prospective of DQL is as bright as other emerging and successful technologies out there; I have been actively using it and being very dependent on it compared to GraphQL which lacks some essential features like facets. Despite its convention and widespread usage, I believe GraphQL needs some innovation or perhaps even renovation.

Update: After thinking it once again, I apologize for sounding a bit imposing. I shouldn’t be doubting your project, and this concern of mine shouldn’t be Dgraph’s team responsibility to begin with. That being said, I hope you guys never lose intention to make DQL consistently grow for everyone and possibly make GraphQL take some example from DQL. :slight_smile: