A businessman with his hands raised and a confused look, doesn't know the answer to the question...
PHOTO: Shutterstock

Dubbed as the “query language for your API,” GraphQL has been hailed the successor to REST API. In fact, according to the latest weekly usage figures released by Drupal for their GraphQL project, there has been an approximate 40 percent increase in usage of GraphQL since the end of December 2018.

To get familiar with what GraphQL is, and how it is different (and possibly superior) to REST, we spoke with leading industry experts and practitioners.

What Is GraphQL?

Created by Facebook in 2012, GraphQL is a syntax that enables a client to specifically define what data it needs from the server. When the query is sent to the server, the requested data is then returned back to the client as a JSON. In 2015, GraphQL went open source.

Mark Olson, senior communications manager at Trulia, explained that GraphQL is an alternative to REST API. “GraphQL, sometimes called 'a query language for your API,' is an alternative to the REST architectural style that allows clients to request the data they need, using a clear and self-documented interface,” said Olson.

Olson said his firm utilizes GraphQL and that the technology plays a key role in their new microservices architecture.

Related Article: Cloud Service Models (IaaS, SaaS, PaaS) + How Microsoft Office 365, Azure Fit In

GraphQL vs. REST API: What’s the Difference?

According to Ryan Anderson, platform architect at Perfect Sense, both GraphQL and REST utilize JSON as the primary data communication format. But GraphQL takes the “concepts” of REST and builds on top of it. The main difference, from an architectural perspective, lies in the endpoints. “A GraphQL endpoint is a RESTful endpoint, not the other way around,” said Anderson.

Due to this differentiator, GraphQL could “superset” or become a new standard for RESTful architectures. To illustrate how this might be the case, Anderson provided an example of how the endpoints of both REST and GraphQL would look like in an API-first CMS:

  • www.my-cms.com/api/get/articles
  • www.my-cms.com/api/get/galleries
  • www.my-cms.com/api/get/video

And in GraphQL, a typical single endpoint may look like:

  • www.my-cms.com/api?query={...parametersOfQuery}

Anderson explained that this difference in the structure of endpoints “allows us to [...] focus less on the structure of the endpoints, and more on the schema of our data. GraphQL takes this approach a step further as well, by providing something called the GraphQL SDL (Schema Definition Language). This is similar to OpenAPI/Swagger for REST, but instead of using XML files it uses a structure similar, but not quite the same, to JSON.”

Anthony Blardo, manager of development operations at Skuid, added that the endpoints in REST are predefined in the back end of an application so that it can return data that is relevant. GraphQL has a different kind of approach.

“GraphQL has no coupling of the mechanism of retrieval from the data you retrieve,” said Blardo. “A GraphQL client would have a working knowledge of the structure of the resources it can interact with, but no specific logic for how to do that retrieval. With a GraphQL back end you can also allow the client to determine what fields on the resource are required for the use case of the request.”

Related Article: Edge Computing vs. Fog Computing: What's the Difference?

Is GraphQL Superior to REST API?

According to Samer Buna, Author of Pluralsight and Curator at jsComplete.com, GraphQL resolves the following three problems associated REST.

The Need to Do Multiple Round Trips to Fetch Data

With GraphQL, you can retrieve all the initial data in a single roundtrip to the server. To achieve the same with a REST API, you would need to introduce unstructured parameters and conditions, which are difficult to manage and scale. “The main advantage of GraphQL over REST is that it separates the data from the protocol and allows the API client to specify what data should be returned on a given API call,” said Jeff Bohren, chief software engineer at Optimal IdM. “This solves a common problem in REST where getting one set of data requires multiple API calls.”

Being able to specify the exact data you’d like exposed or retrieved solves the issue of “overfetching” and “underfetching” associated with REST.

Clients Dependency on Servers

In GraphQL, the client can utilize a request language which can:
  1. Eliminate the need for the server to hardcode the shape or size of the data.
  2. Decouple clients from servers.
This means users can “maintain and improve clients separately from servers,” Buna said.

Poor Front-End Developer Experiences

GraphQL enables developers to express their data requirements of their UI using a declarative language. “[Developers can] express what they need, not how to make it available. There is a tight relationship between what data is needed by the UI and the way a developer can express a description of that data in GraphQL,” Buna said.

However, regardless of these benefits, Bohren advised brands not to come to an immediate assumption that GraphQL is an alternative to REST. “GraphQL should not be thought of as an alternative to REST, but an additional API technique that can be deployed side by side with REST in the same API set. Although GraphQL may be better at searching data, there are other facets that would be better suited to REST,” said Bohren.

Are you planning to use GraphQL instead of REST, or will you be combining the two? Please share in the comments or social media.