Follow BigDATAwire:

November 7, 2018

Will GraphQL Become a Standard for the New Data Economy?

(GarryKillian/Shutterstock)

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.

Instead of point-to-point REST connections….

“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 3rd party APIs or whatever it might be,” Schmidt explains to Datanami. “You need a way to get the data out of the cloud from multiple 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.”

…GraphQL puts a more extensible data graph in the middle of the connections.

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. “It’s the difference between going to a grocery store, where you can buy anything you want and get back whatever is on your shopping list, versus a grocery store that only sells meal kits,” he says. “You can have meal kit number one, two, three, four, or 50, but you have to order by numbers. If you want something different, you have to call up the supermarket and persuade them to offer a different meal kit with a different combination of ingredients.”

Apollo’s GraphQL platform is composed of multiple pieces

Facebook started its project to rationalize its API calls behind GraphQL years ago, but there was little chance that the Web giant would open source the technology, since it was enmeshed in so many other Facebook tools and technologies. Schmidt, who had helped build the Meteor JS framework that is often used with React, was about to start developing something to abstract and federate API calls when he discovered that Facebook already had designed GraphQL.

“When we heard about the work going on at Facebook and the fact that they had a syntax for this already, we said, hey, let’s have more standardization rather than less,” Schmidt says. “Let’s go ahead and use the syntax that Facebook created. It’s maybe not exactly what we would have done, but that way we can have compatibility with all the interest that’s starting to happen in the React community around this technology.”

According to Schmidt, the Apollo GraphQL client accounts for 95% of the nascent market for GraphQL on Web, iOS, and Android platforms. With today’s launch of the open-core Apollo GraphQL platform, the company is bundling its GraphQL client along with its Apollo Server, which translate existing APIs and backends into GraphQL. There is also a new GraphQL query execution gateway, which caches data and provides server- and edge-based processing,  along with a suite of governance and management tools for developing and operating large-scale data graphs.

The capability to build a data graph with GraphQL brings other advantages that could bolster data science initiatives, according to Schmidt.

“With a graph API, you have a very fine-grained understanding of exactly which clients are fetching exactly which fields in their data,” he says. “It’s not just the data in your graph, but it’s the data about how your graph is being used. I think people will find a lot of value in that as we go forward because it exposed a lot of interesting information about what your customers and partners are actually doing…. You have a higher level understanding with less ahead-of-time custom development work.”

GraphQL is relatively new, but it has already been adopted by many big companies, including Airbnb, Netflix, CNBC, The New York Times, and GitHub. The product is being downloaded at the rate of 300,000 per week according to Apollo, which has raised more than $31 million in venture funding across two funding rounds. GraphQL has already piqued the interest of developers, if data from Google Trends (see above) is any guide.

It’s unclear if GraphQL will become the new standard for data and application integration. Schmidt admits there is a bit of a learning curve for developers to get up to speed with the technology, and there is another layer of software to install and manage. Just as application developers had to learn SQL  to fetch data from databases themselves, developers need to learn GraphQL’s syntax to gain the benefits.

But if the technology can deliver on some of the claims, there’s no reason to think that GraphQL — which is part of the GRANDStack (GraphQL, React, Apollo, Neo4j Database) —  could emerge to transform the relationships that developers have with data.

Related Items:

Why Knowledge Graphs Are Foundational to Artificial Intelligence

Welcome to the Open Analytics Era

BigDATAwire