Getty Images

Tip

What to know about GraphQL vs. REST performance

Both GraphQL and REST aim to simplify API development, but they handle data differently. Carefully consider how those differences might affect performance.

Developers are gaining new levels of flexibility for building applications through the growth of server-side technologies. And with the advent of microservices, highly detailed API creation has exploded. In addition to providing increased facility for designing back-end resources, GraphQL simplifies building front-end applications by precisely defining the data gathering process.

Thanks to the support of an active developer community, GraphQL is an open standard that specifies multiple ways that clients can consume an API, regardless of how that API is provided. The well-established REpresentational State Transfer (REST) approach enhances separation of client and server based on a stateless, one-time exchange of information. Let's explore the benefits of that flexibility as well as some of the key advantages of GraphQL versus REST services.

A closer look at GraphQL

Originally created by Facebook in 2012 and converted to open source in 2015, GraphQL is a strongly typed system that simplifies API building and clearly delineates the query process. In fact, these explicit query capabilities allow the origin to be either a database or a web service. Moreover, a developer can simply add a field to a query to gather new, pertinent data as needed.

Such flexibility is due to GraphQL's highly refined data retrieval process, clearly defined structure and introspection. GraphQL passes each query through a single endpoint, enabling more precise data retrieval. This approach solves the problem of overfetching or underfetching of data, an issue common to RESTful APIs. By contrast, each GraphQL client specifies the exact data parameters to the server based on predefined schema.

Due to a substantially reduced number of endpoints, GraphQL can acquire all the data with one call and structure this information in JSON format for fast retrieval. And since it's transport-layer agnostic, the API server can exchange data over any protocol, including HTTP, HTTPS, WebSocket and TCP.

To understand the effectiveness of GraphQL, it's useful to look at some key features:

  • Refined data retrieval. Developers can employ the GraphQL schema definition language to define how the client accesses data. Employing an explicitly defined schema, application front-end and back-end development teams can work independently. They can then ensure continuous resource updates by simply submitting changes via their source code repositories.
  • Defined structure. Through its explicit structure, GraphQL makes it easier to define requests, initiate autocompletion within an integrated development environment and automatically generate API documents. With GraphQL, developers can work in a declarative style and select specific data or designate the required operations that should be performed.
  • Introspection. The ability to use dynamic introspection to query the type system and gain detailed information about GraphQL schema is especially useful. Developers can run introspection queries to learn about the available types of GraphQL schema. They can also view those different introspection schemas based on preset business privacy rules and access control features.

While these represent advantages of a GraphQL approach, downsides include error handling and file uploading. For example, to uncover an error in GraphQL, developers need to parse messages that use different formats or add custom fields. On the other hand, file uploading isn't part of the GraphQL feature set, so implementation is up to the developer.

Adding dependencies in GraphQL can help alleviate issues, however these may not be accessible to all programming languages. With RESTful services, developers only need to check the response states to pinpoint a server error or a missing resource.

Steps of a GraphQL query.
GraphQL enables developers to input specific, customized queries that output only relevant, desired data.

GraphQL vs. REST

A recent State of GraphQL report found that based on a survey sample, 38.6% of today's developers are happy with the GraphQL ecosystem. In general, the appeal of GraphQL is based on its overall API efficiency when compared with REST APIs. For example, RESTful services frequently return large amounts of unusable data mixed with relevant information and these are usually the result of multiple server queries. Such inefficiencies also increase the time it takes for a client to return all the required data.

While GraphQL offers advantages, REST APIs will be preferred in certain development scenarios. For example, RESTful services can make effective use of HTTP caching mechanisms -- unlike GraphQL, which doesn't support browser and mobile caching to expedite calls.

Web caching is also harder in GraphQL compared to REST, since a REST API provides many endpoints versus a single endpoint in GraphQL. Developers who use REST can more easily configure a web cache to match URL patterns, HTTP methods or even certain resources. Developers can fine-tune the searches by using multiple, specific queries in RESTful services.

Moreover, REST APIs can leverage HTTP status codes to detect errors and ease the API monitoring process for developers. By contrast, GraphQL makes it difficult to handle these errors and cumbersome to monitor APIs. Finally, RESTful services simplify the SQL log process, making it relatively easy to optimize these queries. The dynamic nature of GraphQL's queries can make that identification process quite complex.

However, GraphQL is gaining adherents as the dominant standard for API building. By giving more control to the client and enabling it to dictate exactly the data required, GraphQL solves the problem of random data returns.

Developers are looking for every opportunity to streamline their app designs and speed up processing. GraphQL fulfills those demands by enabling faster code development and a more structured approach to the creation of data-driven applications.

Next Steps

The 6 non-negotiable REST architecture constraints

Falcor vs. GraphQL: The differences that matter

Dig Deeper on API design and management