Don’t look now but a new language called GraphQL is emerging that could radically simplify how developers use APIs to get data into applications, and potentially provide a graph-like alternative to procedural REST. The company behind the open source software, Apollo, today announced the GraphQL Platform to standardize access to the new technology.
GraphQL was originally developed at Facebook to provide a more powerful way to assemble the various pieces of data that compose its social media platform. The social media giant wanted to create a higher abstraction to reduce the burden on developers to know specific details of all the various API calls for the different elements that Facebook exposes on its screen – like which users have liked a post, which have commented, and whether they’re friends with you, etc.
While APIs themselves provide a good method for calling data and processes, there are some big limitations in the REST approach to API calls that the computer industry has gravitated towards, explains Geoff Schmidt, the co-founder and CEO of Apollo.
“For any screen in an application, there might be a 100 different pieces of data that you need to render that screen, and it might come from a dozen different places in the cloud, whether database or microservices or 3 part APIs or whatever it might be,” Schmidt explains to Datanami. “You need a way to get the data out of the cloud from multiplied disparate systems down into your phone.
“The current generation of API technology — REST and SOAP – are 20 years old, and were never designed to do that,” Schmidt continues. “They go back to the digital Stone Age. What people have found is they really struggle to build modern apps on top of that old API technology.”
The disconnect stems from the rigidity of the REST and SOAP approaches, which rely on procedural snippets of code that were designed to do one thing and are not easily modifiable. A REST call will reliably run a chunk of code to fetch a pre-written report or a specific piece of data, Schmidt says. “But if you want a different kind of data, tough,” he says. “You have to call the backend team and say ‘Hey I’m adding a new screen, please make this new API to return a different combination of things.”
The beauty of GraphQL, Schmidt says, is that it emulates the elegant simplicity of a graph database in terms of how it understands and exposes the data and application connections that the individual APIs represent. “This kind of sits on top of all your existing services and super-imposes a graph on all those cloud assets and resources so application developers can freely query that without the friction of having to create a new REST endpoint for every new use case,” Schmidt says.
And since it’s fully compatible with existing REST and SOAP APIs, developers can utilize GraphQL to federate access to the data and application sources that they represent, including relational databases, NoSQL data stores, HDFS, S3, or practically any other data repository, he says.
“When it comes to things like databases, we want to use the right tool for the job. We might use a SQL database for this, a NoSQL or a graph database for that. You might use a search-oriented database like Elasticsearch. We might disturbed that data over multiple clouds, public or private,” Schmidt continues. “This lets you leave all that stuff where it is, let those other teams still continue to maintain it, but present a unified interface on top of that so the application developer can freely draw on it.”
Schmidt uses a shopping analogy to demonstrate the power of GraphQL and the relative narrowness of the predominant REST method.
