This article was originally posted on Mooncamp’s blog and authored by Mooncamp’s founder and CTO, @Joschka. Article’s link: https://mooncamp.com/blog/fast-tracking-mooncamps-development-speed/.
Fast-tracking Mooncamps development speed with Dgraph
This is the story of how Mooncamp’s development team found the holy grail. The holy grail that allowed speeding up development by an insane amount. Think GraphQL you can set up using almost no code. Think declarative, powerful APIs. Think the most complex access management problems solved using simple, easy to maintain configuration.
Mooncamp’s founder team has a strong technical background. Most of us have several years of experience building web applications and SaaS products. We knew what technology we could trust to accelerate our development speed, primarily we were sure about using GraphQL to communicate data between browser and database. If you ever built something with GraphQL, you know that an implementation of this setup ordinarily entails a relational database and a bunch of resolvers. Although we understood that choosing this setup would bring us the best cost-to-value ratio, we also recognized that building and maintaining this setup requires a lot of work. The exact opposite of what we were aiming for. Additionally, there are problems with this solution that are very hard to solve, such as the famous n+1 problem. Not very ideal.
Joining the graph database community
Independently of discussions around the technology stack, we were fascinated by the concept that graph databases bring to the table. The notion of finally making relations a first-class citizen in a database was pretty appealing, especially since we often felt disappointed by the way relational databases handled relations. We absolutely didn’t miss the irony here. Dgraph was especially appealing for us for two reasons: It is written in Go, a language all of us appreciate and love. Also, it provides a GraphQL-like query language. I might have mentioned before that we are already pretty big fans of GraphQL. A database that simply solved GraphQL for us? Yummy! So we began joking about just switching to Dgraph and simply wiping all the custom GraphQL code we have built up so far. So much code would become irrelevant, our codebase would be so much cleaner and easier to maintain! Well, we were of cause just joking, because there are too many questions without any answer, immediately after giving this serious consideration. These are a couple of the hardest ones:
-
Is Dgraph even stable? Databases carry a lot of responsibility. We didn’t want to lose our customer’s data overnight. Yikes!
-
How do you validate the data that you are stuffing into Dgraph? We can’t rely on the client to always follow our business rules regarding data consistency. Dgraph doesn’t know how an email should look like, or that you can’t change a user’s email.
-
How do you do access management? And there are so many levels to this! First, there is multi-tenancy. Imagine customer of account A reading the data of account B. This would kill our business. But there is more: our application needs to be extremely privacy-aware, which means complex access management rules, most likely some sort of role-based access management.
Also, there had to be a reason why no one was doing this, right? There had to be some serious, non-solvable downside to all of this! Well, this post is a success story, because, dear reader, we did it! We made the switch and solved nearly all the problems (we are still working on details, but the system is deployed and in-use). And let me tell you what a win this was. We are now able to add features blazingly fast and are building upon an insanely scalable codebase.
We did it 
Let’s go through the questions I asked above. First, to address stability: the open development model of Dgraph helped us build trust in the Dgraph team. Issues that we post on their Github are recognized and solved reasonably fast. Recent Jepsen tests show that Dgraph is reliable Jepsen: Dgraph 1.1.1. We also managed to overcome the biggest technical issues we identified early on: Data validation and access management. This is done by proxying every request to Dgraph. Specifically, the proxy handles the following use-cases:
-
It automatically filters the query response based on user access rights. We developed a configuration DSL that allows us to express very precise access management rules. For instance, you can give read access to the company, while allowing write access to the marketing and engineering team. Let me emphasize that no code is necessary to enforce these rules. This is done purely through configuration.
-
It validates incoming data based on a declarative configuration. The configuration can be extended using custom validation rules that are implemented using user-written code. This is one of the few examples our backend allows manually written code.
-
It makes sure the user is only able to update the nodes she is allowed to update. This is configured using the same DSL we are using for query requests.
Implementing this technology was a ton of fun, but also a ton of work. The good news is, that in the near future you can probably enjoy all these benefits, as Dgraph is working on a GraphQL solution that is solving all these issues as well. Have a look at GraphQL API - GraphQL.