Analyzing GraphQL Performance: A Case Study

Analyzing GraphQL Performance: A Case Study

Mafalda Isabel Landeiro (Instituto Superior de Engenharia do Porto, Instituto Politécnico do Porto, Portugal) and Isabel Azevedo (Instituto Superior de Engenharia do Porto, Instituto Politécnico do Porto, Portugal)
Copyright: © 2020 |Pages: 32
DOI: 10.4018/978-1-7998-2531-9.ch005


Web applications today play a significant role, with a large number of devices connected to the internet, and data is transmitted across disparate platforms at an unprecedented rate. Many systems and platforms require applications to adapt quickly and efficiently to the needs of consumers. In 2000, the Representation State Transfer (REST) was introduced, and the developers quickly adopted it. However, due to the growth of consumers and the different needs, this architectural style, in the way it is used, revealed some weaknesses related to the performance and flexibility of the applications. These are or can be addressed with GraphQL. In this chapter several alternatives to use GraphQL are explained and their benefits in terms of performance and flexibility. Some prototypes were implemented in an organization, and the results of some experiments were analyzed in light of possible gains in performance.
Chapter Preview


Web applications are becoming more common and there is a growing need to respond quickly to deliver the best possible experience for consumers. Data management service architectures are common because the application core must be centralized and connected to multiple systems and a variety of platform types.

Once introduced, Representational State Transfer (REST) was quickly adopted by developers because of its main features: scalability, interoperability, simplicity, and extensibility (Fielding & Taylor, 2000). However, in large organizations that deal with complex entities and requests, this architectural style has begun to reveal some drawbacks.

In 2015, Facebook introduced GraphQL, a technology that can improve application flexibility, performance and memory utilization. Since multiple access to an endpoint is no longer required and it is no longer necessary to specify what data the client wants to receive, it was quickly adopted. With GraphQL, one can reduce the number of requests needed to get the desired data.

Since GraphQL was developed to optimize a REST API, it is easy to point out some aspects where this query language surpasses this architectural style. Some studies have compared their use according to various criteria. Some similarities and the lack of maturity of GraphQL were identified at this time (Stubailo, 2017). Several quality attributes were analyzed, and it was concluded that REST has superior performance in atomic calls, while GraphQL handles better overfetching and underfetching (Guillen-Drija, Quintero & Kleiman, 2018). Another study showed the best network response times with GraphQL (Vázquez-Ingelmo, Cruz-Benito & García-Peñalvo, 2017).

Other companies such as Netflix (Shtatnov & Ranganathan, 2018), GitHub (Torikian et al., 2016) and Paypal (Stuart, 2018) have also introduced GraphQL as an alternative to REST APIs and presented their conclusions highlighting the benefits.

The Institute of Systems and Computer Technology, Technology and Science (INESC TEC) has a one-year web platform called INESC TEC Research Information System (IRIS), which essentially manages research and human resources.

This application handles queries of varying complexity, mainly in the area of ​​project management, and the actual solution has some performance issues. When the response time is longer than ten seconds, users are known to lose their attention (Möller, 2010). This web application has a backend that follows the REST architecture, and the frontend is one of the main consumers of the available REST APIs.

IRIS has been enhanced with many new features, and the need for integration with different platforms has increased, especially for the project management module. Using REST APIs raises some data query issues, such as:

  • The necessity to call more than one endpoint to obtain the necessary data;

  • Consumers receive more data than necessary;

  • The performance started to degrade.

Some temporary solutions have been considered, e.g., customizing the server response to provide the most data needed in just one request. However, an increase in response size was observed with only a slight improvement in performance.

In addition, some studies show that REST APIs were used to meet the needs of different consumers. However, this solution is not optimally resilient, even if best practices are followed, as in some cases many endpoint requests may be required or additional data may need to be received (Vázquez-Ingelmo et al., 2017). Therefore, a more flexible and efficient solution is sought.

Despite recent developments with GraphQL, there is a lack of understanding about the possibility to conjugate its flexibility with performance.

In terms of data query, several architecture solutions using GraphQL have been explored to understand the alternatives for improving IRIS performance and flexibility. The following hypotheses were formulated with IRIS as the basis for our study:

Key Terms in this Chapter

Performance: API fulfillment based on time and size.

REST: The architectural style that allows communication by HTTP.

Query: Search with criteria to obtain specific data.

GraphQL: Query language created by Facebook to mitigate performance issues.

Data: All the information that is available for querying.

Flexibility: Facility how the application adapts to new consumers necessities.

Response Size: The size of the response that the consumer receives.

Response Time: The time between the request accepted by the API until the consumer receives a response.

Complete Chapter List

Search this Book: