Analyzing GraphQL Performance: A Case Study

Introduction

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: