GraphQL, the Facebook-backed open source tech, is making waves across the internet right now. Some people claim it’s going to revolutionize API design and leave REST in the dust. But what is it exactly and why the fuss? James Governor over at Redmonk explains.
Despite its name, GraphQL is not much about graphs and it’s not really a query language. It’s much more about designing your APIs more effectively and getting very specific about how clients access your data. The primary advantage of GraphQL over REST is that you can access a nested object or field without having to make multiple API requests. One call to one endpoint is enough. You simply send a string that describes the data you want and how you want it structured and you get it back in JSON.
Its promised advantages over REST are attracting some of the biggest names in the business. GitHub CEO Chris Wanstrath recently stated that all its APIs will be developed with GraphQL from now on. The motive behind the move? GitHub gets more API calls than site requests, in part because of its reliance on REST.
It’s not alone. The New York Times has decided to do its major backend redesign on the back of GraphQL. But what about Facebook, the creator of GraphQL? They’re using it to describe their API structure and to provide something easy for mobile devs to learn. They receive billions of API requests a day with it, so you can be sure it scales. One of the advantages that Facebook emphasizes is that the structure of the query mirrors exactly the structure of the JSON response, which helps developers know exactly what’s going to be returned by the API.
But will GraphQL really replace REST? Phil Sturgeon thinks, in some cases, yes:
“If you need a highly query-able API, expect an array of clients that need small and different data, and can restructure your data to be inexpensive to query, then GraphQL is likely to fit your needs.” In its favor is also that the companies adopting it are exactly the ones that developers like to emulate.
GraphQL is not without issues, however. Current caching models don’t map to GraphQL. Sturgeon explains: “Due to the way GraphQL operates as a query language POSTing against a single endpoint, HTTP is demoted to the role of a dumb tunnel, making network caching tools like Varnish, Squid, Fastly, etc. entirely useless.”
On the other hand, GraphQL makes some things much easier. Its introspection capability will help with self-documenting APIs, while others are building services that will make GraphQL the go-to technology for serverless APIs. graph.cool, for example, lets you use GraphQL to build apps and services purely with third-party platforms like Algolia and Auth0. James claims that Authory is already using GraphQL in this way to offer journalists a single point of access for their content. He claims that this makes GraphQL not so much a REST competitor as a Firebase competitor.
James concludes by emphasizing that GraphQL is a natural fit for API-driven apps that rely on serverless technology. But he stresses that despite its advances over REST, REST will not disappear overnight. GraphQL will however likely find widespread adoption among high scale sites looking to reduce their volume of API requests.