Why GraphQL is a serious alternative to the REST API [Q&A]

GraphQL -- in case you haven't heard of it -- is a rapidly rising query and manipulation language for APIs. It's designed to make APIs fast, flexible and developer-friendly, and it moves the complexity of data fetching from the client to the server side.

We spoke to Pete Crocker, director of solutions engineering at OpsMill, to learn why it's increasingly being employed as an alternative to the more established REST API.

BN: Let's start at the top, can you give us a quick overview of GraphQL?

PC: GraphQL is a relatively new method for creating APIs. Designed to make APIs more efficient, GraphQL is ideal as an alternative to REST for executing complex and variable data exchanges.

REST created the foundation for APIs that use HTTP for requests for data transfer and works well for relatively simple data exchanges. GraphQL adds structure and capabilities to enable greater efficiency, precision, error-handling, and backwards-compatibility.

BN: What's the history of this? Who created GraphQL and why?

PC: GraphQL was initially created and used internally by Facebook in 2012 while developing the News Feed section of their IOS application. In 2015, it was released as an open-source project, then in 2018 the project was moved from Facebook to the GraphQL Foundation, which is hosted by the Linux Foundation.

The main reason for GraphQL's development at Facebook was to overcome the challenge that REST-based APIs were too verbose and rigid to produce news feeds efficiently. While this was the original use case, it was soon discovered that GraphQL brings advantages for any API use case where high volume, variable, and complex data interactions are required.

GraphQL is a sound alternative for REST in many situations, though the two can also be complementary in some cases. They share common API architecture characteristics and they both use a client-server model with stateless servers and communicate via the HTTP protocol. In addition, GraphQL and REST both support similar data formats such as JSON and can work with any database and programming language.

BN: Can you dive deeper into the technical limitations of REST that created a need for an alternative?

PC: There are a number of limitations of REST that GraphQL addresses. But we'll focus on some of the most critical. First is REST's fixed structures for data exchange and overfetching. REST APIs use pre-defined data structures for exchanging data. This simplifies things,but means that even if you need one piece of data from a data structure, you always have to receive the whole thing. That’s a resource-intensive process.

Another big issue is that REST uses multiple endpoints for different data resources. Generally speaking, if you need two different types of data, you need multiple REST API requests. This leads to an underfetching phenomenon, where you can’t transfer what is needed with a single request.

Finally, REST suffers from weak data typing and limited error checking. REST data does not enforce typing, which means that the client must figure out how to interpret the formatted data when it is returned. Weak typing makes error checking more difficult and leaves it to the client. With simple data sources where resources are easily and clearly defined, this is fine, but in cases where there are complex data sources, this ambiguity and difficulty in error handling is a significant disadvantage.

BN: How exactly does GraphQL solve these problems?

PC: While REST is a set of rules to define structured data exchange between a client and a server, GraphQL encompasses a query language, schema-driven architecture, and tools. Here's how it addresses the issues outlined above:

• Mandatory schema: GraphQL defines a schema for queries.
• A single URL endpoint: Rather than separate URLs for different resources, GraphQL utilizes a single URL endpoint for all data exchanges.
• Flexible, client-defined data exchanges: Unlike REST where you request a resource and get all of it whether you want it or not, GraphQL allows you to create flexible and precise queries to fetch just the data you want.
• Strong typing: GraphQL data is strongly typed, so the client will always receive data in a predefined format that is well understood.
• Better error handling: Due to its predefined schema and strong data typing, invalid requests can be elegantly rejected and served an automated error message.

BN: What sort of use cases is GraphQL best for?

PC: When you need to execute complex data exchanges across multiple data sources, and where there may be a high degree of variability in client requests, GraphQL offers a significant efficiency advantage in terms of the number of queries needed and the amount of data fetched. These complex use cases also benefit from better data typing and error checking available in GraphQL.

One example of a complex data exchange use case that is ideal for GraphQL is managing infrastructure asset, configuration, and service data for the purpose of automating hybrid enterprise networks, data centers, cloud resources, and security policies.

Image Credit: Alexandersikov/Dreamstime.com