Observations on Dgraph

Recently I created a POC web app based on Dgraph database. I used Svelte for front-end and Svelte-Apollo for GraphQL communication. You can find more information about the POC here.

In this post I am documenting my observations and challenges I faced while building the POC.

Development Experience 

Setting up the development environment for Dgraph, Svelte, and Svelte-Apollo is comparatively easy. I was able to resolve any hiccups with the provided documentation.

Dgraph

I used Dgraph's Slash cloud service instead of setting it up locally. The cloud service has very nice user interface and handy tools. These were missing in the local Dgraph setup. The cloud service provides query generator which is very convenient. It makes writing GraphQL statements a breeze.

Svelte

Setting up Svelte is very straight forward. I just followed the instructions provided in the website and it worked without any hiccups.

Svelte-Apollo

The initial library I used for GraphQL communication is urql. But urql has a major bug. It is not possible to implement refresh feature with the default caching mechanism. The fix for this was to change the caching mechanism. But then the development with urql will not be straightforward anymore. So I switched to Svelte-Apollo.

Setting up Svelte-Apollo was easy but development was a bit challenging. Svelte-Apollo is built on top of Apollo GraphQL library. Even though Apollo GraphQL library has very good documentation; Svelte-apollo has only one page documentation which is it's Github readme file. There is not much of choice when choosing a GraphQL library when working with Svelte. So I persisted and eventually got it working. 

Challenges

I feel most of the challenges I faced are because of the features of the architecture elements. In this POC the main architecture element is Dgraph. Its features are that it is a graph database. And it uses GraphQL for external communication.

Query language

Traditional SQL cannot be used with Dgraph. We have to use a modified GraphQL called DQL. Another query system called RDF can be used. From the comments on Dgraph forum; it says it doesn't implement the complete RDF Spec. If I wanted to use it it is another thing I will have to learn to use Dgraph.

Dgraph cloud service provides a GraphQL generator. I found myself using it often and it makes writing GraphQL queries a breeze. You can also instantly test it out also.

Foreign Keys

Dgraph foreign keys are not like traditional foreign keys. It doesn't support cascade on delete feature.

In the POC the feature that I wanted to implement was when you delete a task then all it's subtasks will be also be deleted. And when you delete a project all it's tasks and subtasks will also be deleted.

This is very easy implement in traditional database with the cascade on delete feature. To implement this feature in Dgraph first you have identify all the items that needs to deleted. You need all the id's of these items. The use the delete task/subtask/project query to delete all the items. GraphQL allows us to pass multiple delete statements in one query. So one request is sufficient to delete all the nodes.

Stored Procedures

Dgraph doesn't support stored procedures. So Business logic cannot be written in database. The business logic then should be written in the front-end or middleware. 

One plus point when using GraphQL is that you can combine multiple update/delete/insert statements.

Aggregation queries

Aggregation queries are supported in Dgraph. But it is very limited.

In the POC app I wanted to show task count for each project and subtask count for each task. In the traditional system I would have used an inner query to get the children count. I couldn't find a way to do this. Not sure if this is possible in GraphQL.

We will need to implement it as a separate service. And for every change we will have to send two requests for page refresh. First to get the updated tasks and then to get the count data.

I tried to overcome this by adding a count column for each project and task. But I found this to be very buggy. Instantly adding multiple tasks can mess up the count very easily.

Constraint Checks

Constraints checks cannot be set in Dgraph. For example unique constraints. Unique constraint is a very common constraint used in traditional database. If you want to ensure uniqueness in your data in Dgraph then you have to set put that logic wherever you put the business logic. But this can get very buggy if data is inserted from multiple sources. 

Advantages of Dgraph 

• Your frontend can communicate with Dgraph directly using GraphQL. 
• Dgraph is also designed to be highly scalable. 
• Dgraph can be easily integrated with an auth system. 

Conclusion

I feel Dgraph can be successfully used for applications which just need CRUD operations. If your application has lot of business logic then it is not recommended. Although you can use Dgraph as a support database. Dgraph is a highly performant graph database. If you have a highly interconnected dataset then Dgraph is can be used to parse that data.

Edit Log:

• Added links.