A GraphQL solution to back-end operational woes

Commentary: GraphQL is popular for front-end development teams but sometimes painful. Dgraph has a possible backend-as-a-service solution.

Programmers and developer teams are coding and developing software — Image: iStockphoto/ijeab

For all the problems with 2020 (oh, so many), it’s incredible that the lowliest of developers has access to the technology powering the world’s most sophisticated IT operations. Want to run your technology infrastructure like Twitter? Intuit? Uber? Capital One? Or Facebook? Chances are good that the company has already open sourced the building blocks, just as Google did when it turned the essentials of Borg–its own homegrown “manage your entire data center as a single machine” abstraction–into Kubernetes. That move almost immediately took the Docker container movement from enterprise architecture theory to mass adoption.

A similar story may be unfolding today with GraphQL. Facebook open sourced GraphQL in 2015 as a superior data-fetching approach for web development and as a challenger to REST, and it’s become one of the shiniest new objects for front-end development teams. But GraphQL is an API language, not a running system, and most lack what Facebook had: An army of uber engineers to make GraphQL work “atop a stack of abstractions which had been in place [well before the introduction of GraphQL], most of which [were] designed by…the Product Infrastructure Team,” as GraphQL co-creator Lee Byron has written.

Which brings us to the problem with such open source code: It’s one thing to have it, but quite another to operate it. In the case of GraphQL, one emerging option for mere mortals to make sense of this Facebook-spawned code comes from a former Google engineer.

Helping front-end developers forget about the back end

To get started with GraphQL, developers face a hard choice: They can either build and maintain their own GraphQL back end, which can take significant time and engineering resources, or they can deploy a complicated overlay on top of a relational database. Despite these potential hurdles, web developers really want to use GraphQL–89% of respondents to the 2019 State of JavaScript survey said they either plan to use it again or want to use it for the first time. And yet, even if you’re Facebook, actually setting up a GraphQL back end can be tough.

Fortunately, there may be other options.

SEE: Special report: Prepare for serverless computing (free PDF) (TechRepublic)

For one, Dgraph Labs’ just launched Slash GraphQL delivers a GraphQL backend-as-a-service that aims to completely abstract away the complicated setup considerations mentioned above. Its design is rooted in lessons learned at Google, where Dgraph Labs founder and CEO Manish Jain built the graph indexing and serving system that powered Google’s Knowledge Graph infrastructure. For Jain, graph databases–not relational databases–naturally fit developer workflows, and are a more ergonomic experience for developers using GraphQL. Many early web pioneers started with relational databases because that was the state of the art at the time. However, as Michael Compton, GraphQL lead at Dgraph, put it, “Google, Facebook, Twitter, LinkedIn, and others all moved [applications off relational databases] once they were large enough to have the engineering effort to build an in-house graph solution.”

But, again, most companies can’t find or afford the necessary talent to do this.

SEE: How to build a successful developer career (free PDF) (TechRepublic)

Earlier this year I wrote about the JAMstack trend with the world’s 10 million JavaScript developers who are seeking to split the front end from the back end so that site development can happen faster and independent of the back end. Slash GraphQL is a novel GraphQL approach in that it allows web developers to simply use GraphQL and create their mutations and traverse data without having to reason at all with setting up tables or any of the underlying complexity on the back end.

“Slash GraphQL takes away the work of building a fast and scalable GraphQL backend,” said Jain in an interview. “With Slash GraphQL, developers click a button and are presented with a /graphql endpoint. They set their GraphQL schemas and immediately get a production-ready back end. Right away they can start querying and mutating data, without any coding whatsoever.”

For front-end developers anxious to run GraphQL without having to fuss with the back-end infrastructure, the Dgraph solution just might pay off.

Disclosure: I work for AWS, but the views expressed herein are mine and don’t reflect those of my employer.