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
Fortunately, there may be other options.
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.
“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.