Virtualization Technology News and Information
VMblog Expert Interview: Dgraph's Quest to Make GraphQL Simple to Use and Performant for Front-end Developers

The 'web giants' have introduced open source technology that has changed how developers build software.  That's true for both backend and frontend stacks, and in their wake, the giants have spawned whole tech movements.  At the moment, that movement on the frontend is GraphQL.

Kubernetes is probably the most pronounced example of an open source backend technology born out of a web giant that went on to become a de facto standard. Originating from Borg, Google's special sauce, back-end server architecture and system running all of Google's infrastructure, including Search, Gmail and Maps, Kubernetes now runs much of the infrastructure that modern developers build, and represents an industry in itself.

On the frontend, Facebook's React has become the most popular flavor of Javascript. And, now, Facebook's GraphQL is becoming the "language of the modern web".  GraphQL is providing new breakthroughs that simplify how developers access, query and iterate on data and is spawning an industry of technologies that help developers build apps. 

In a survey of more than 21,000 developers, the State of JavaScript report in 2019 found that nearly 39 percent had used GraphQL and would use it again, and another nearly 51 percent would like to learn it. Despite that growing interest in GraphQL, a common stumbling block is that GraphQL is an API language, not a running system. I recently spoke with Manish Jain, CEO of Dgraph -- whose recently-released, Slash GraphQL is the industry's first GraphQL-native database backend -aaS.

VMblog:  Tell us about the implementation challenges that GraphQL adopters face and how you are trying to solve that with Slash GraphQL?

Manish Jain:  Front-end developers love GraphQL and how ergonomic it is with modern web development - it's so much easier to query and explore data than, for example, older REST style services. But when you try to use GraphQL on top of traditional relational database systems, you get problems with deep queries - you start running into fanout issues, N+1 issues, and so on. Developers also have to build the GraphQL system from scratch - there's lots of nice GraphQL tooling, but you've still got to essentially translate to GraphQL from some other tech stack, and that means modelling issues and extra code. Having a great data querying language is only half the story, you also need a production-ready back-end.

VMblog:  What makes GraphQL a more "ergonomic" way to deal with the data layer than other data layers?

Jain: With GraphQL, the way data is accessed is a lot simpler and more consumable. SQL, for example, imposes rows of data that you have to parse and reason with and forces you to think in terms of tabular structures, rather than the more natural interlinked graph that arises from your data. GraphQL just gives you JSON.  Web clients are in control of the conversation about exactly what data to return and the backend figures out how to get the information that the front-end requested. 

However, with previous methods, developers' iteration on data models is quite complicated, because everything has to be known in advance or migrated as the data model is iterated upon. These days, developers want a dynamic process that allows for rapid iteration. Slash GraphQL is powered by Dgraph, the world's most advanced graph database. It allows you to add fields, remove fields, relate different data types and entities together. Developers can represent those relationships in a much easier way with Slash GraphQL.

VMblog:  How does Slash GraphQL assist front-end teams that want to use GraphQL?

Jain: By introducing Slash GraphQL we really wanted to give users a way to operate on GraphQL schemas without having to build an entire GraphQL backend infrastructure. Slash GraphQL is a fully managed GraphQL backend service powered by the industry's first native GraphQL database, Dgraph.

GraphQL started as an API problem, and that's why you see a rise of solutions that were built to be a layer onto existing databases. These solutions are relatively fast and easy to implement, but this approach left some harder engineering problems untackled, especially around performance and scalability.

Once getting the GraphQL layer onto the existing databases, developers would find themselves still confronted by the hard engineering problems like n+1, fanout issue, scalability and performance. Users also need to set up tables correctly in an underlying database, before they can set up the GraphQL schema.

The API problem now became a storage problem. To bring out the potential of GraphQL, developers need a database solution that solves the hard engineering problems that exist within GraphQL. That's the reason why we created Slash GraphQL. It's not only easy and quick to set up, the click of a button gets you a /graphql endpoint, but it's also horizontally scalable and distributed. So Slash GraphQL guarantees performance and solves the hard engineering problems for you.

VMblog:  You were one of the primary architects of Google's knowledge graph efforts -- how did that early work inspire your vision for a back-end service for GraphQL?

Jain: Two years after leaving Google, I decided to build Dgraph. Outside of Google, I witnessed the same indecision about graph systems as I did inside. The graph space had a lot of half-baked solutions, in particular, a lot of custom solutions, hastily put together on top of relational or NoSQL databases, or as one of the many features of multi-model databases. If a native solution existed, it suffered from scalability issues.

Google's knowledge graph has thousands of data types, each with 100s of properties. Fitting that into a relational system would be a nightmare. That data modeling problem is what the graph serving system at Google was solving for: a single system to represent the many data types with their sparse properties, and querying across all of them without any barriers or performance concerns. A typical company interested in GraphQL might not have thousands of data types, but the data modeling challenges become clear even with dozens or hundreds of data types.

Nothing I saw had a coherent story with a performant, scalable design at heart. GraphQL needed a horizontally scalable, low-latency graph database with arbitrary-depth joins -- it's an extremely hard problem that a lot of new GraphQL developers might not know they'll have. But we're solving that as a service, so they can just use an API and get going with GraphQL schemas without having to figure out the back-end.


Published Friday, November 20, 2020 7:26 AM by David Marshall
Filed under: ,
There are no comments for this post.
<November 2020>