Building a Native GraphQL Database: Challenges, Learnings and Future - Dgraph Blog

I’m interested in graph databases and have taken a look at Dgraph. Let me say first, I really like the attempt. However, I think GraphQL is the wrong choice for a graph query language.

GraphQL has nothing to do with graphs, except it’s unfortunate naming choice. It was designed to query specific parts of JSON data from an API endpoint. Therefore using a JSON-like syntax made lots of sense for GraphQL.

JSON is a nested data structure. A graph database is not nested at all. It’s a web of interconnected nodes. Using nested object syntax is the wrong choice for a graph query language. I guess you made it work with GraphQL±, by repurposing nested objects to specify the relationships, and introducing some custom syntax on top.

However, the underlying assumption is still wrong: Using syntax for a nested data structure for a non-nested one. Put it simply, using GraphQL for a graph database query language is like trying to use a fork as a knife.

I wish Dgraph would implement a better QL. It doesn’t have to be an existing QL like Cypher or Gremlin, personally I don’t like either of them. Whatever query language you choose in the end, it better not be a fork when what’s needed is a knife.

1 Like