Graph Databases, GraphQL and Dgraph
In the first quarter of 2020, I had the experience of being in a short term advisory role for a company that had built a type of Linkedin…
In the first quarter of 2020, I had the experience of being in a short term advisory role for a company that had built a type of Linkedin product for a specific vertical market. They had done a valiant job, but it was clear that scalability was a problem and they had created a problem for themselves by having used MongoDB as the datastore. The client knew this and wanted to do a rebuild using the neo4j, but despite its popularity, I am not a big fan of it as an implementation of a graph database for a variety of reasons, one of which is that it is written in Java. This led me to hunt around for alternatives which ultimately led me to Dgraph, which I initially liked because it was written in golang but I was won over by just how well the system is built and thought out.
In the process of thinking about Dgraph, they released a private beta for their managed GraphQL backend service called Slash GraphQL. This really caught my attention as it allowed me to just dive in and try out some ideas without having to deal with learning how to install the system. So with that as some preview, I went ahead and signed up for the private beta, I was immediately accepted, I don’t know if there is any real threshold to get access other than they want your information, but a small price to pay.
Let’s cover a bit of the ecosystem before we dive in. While GraphQL has become something of a standard for working with Graph databases, that isn’t what it was developed to do, so Dgraph set out to make something that was more specifically suited by modifying GraphQL into GraphQL+- and I assume the +- in the name is in reference to the fact that they added and removed features from it. When working with Dgraph you can use either GraphQL or GraphQL+-, but keep in mind that those languages are really targeted to backend developers and this new Slash GraphQL environment is targeted at full-stack developers. So with all that said, let’s get into it when we first login we see the following screen:
The quickstart video is definitely worth a few minutes to get a sense of what is going on, in addition, you should read the in-process, quick start guide for Slash GraphQL. The quick start guide has some specific examples and a working ToDo app at the end that you can check out, but I wanted to build something from scratch. I gave it a lot of thought as to various clever things I could do, but ultimately I decided to use the example in the quick start to provide consistency. If you are familiar with GraphQL, then the syntax is easy. If you aren’t, but know how to code and know JSON, then it’s not too hard to figure out. This is probably a good time to note some distinguishing characteristics of Dgraph.
Dgraph doesn’t not run on top of another DBMS, it manages data in a way the is optimized for how GraphQL stores and retrieves data. That means you don’t have to deal with creating the schema for the underlying DBMS and then doing it in GraphQL and try to keep them in sync whenever you need to make a change. That means that Slash GraphQL empowers you to only deal with GraphQL schemes without knowing anything about the database. With that said, let’s create our schema:
It’s as simple as that to get your database up and running, define your tables, items, and relationships, click “Update Schema” and now you have an active GraphQL system that you can put data in, query and more. Next we want to go to the API Explorer to do some GraphQL Mutations (add records).
Now we are going to stuff some data in there:
There is code completion in the editor and some other useful tools, but you can see how the JSON gets formatted out when you run it into the right side pane.
With a simple query, we are able to retrieve the data we just inserted, and you can see how it automatically created that one to many relationship with the user ID’s instead of creating a new entry for each user per task:
The tutorial goes through adding authorization restrictions into the database so that users can only read their own entry, but I’m not going to reproduce that here. At this stage, you’ve got some endpoints that you can access from a web app to try it out programmatically, or you can just keep playing in Slash GraphQL and continue to build and test your system.
It’s hard to express how excited I was with this environment, I haven’t dug deeply enough into Graph databases on my own just because it was a pain to set up on my home system, but with Slash GraphQL, I was easily able to create and test ideas thus reducing my learning and set up time. I will say however that their claim that you are doing no coding whatsoever is kind of a stretch because the schema and mutation directives do require that you understand a specific interface syntax, rather like doing SQL That small nit aside, this is certainly a great tool for learning and prototyping at a minimum.