Since the release of GraphQL in 2015, there have been comparisons between GraphQL and REST due to their similar end results and GraphQL’s innovative approach. In some instances, GraphQL is even seen as a direct alternative or has been used in conjunction with REST.1
Despite GraphQL’s innovative approach and acclaimed potential, in 2020, only 19% of companies used GraphQL, while 82% used REST.2
While REST is far more widely used than GraphQL at the moment, industry leaders and big companies such as Facebook, Airbnb, and Github are adopting GraphQL.3 This article will evaluate the advantages and disadvantages of GraphQL to determine when it may be better to use GraphQL over REST.
GraphQL vs. REST
Figure 1: Representation of the GraphQL process
GraphQL is an open-source query and manipulation language for APIs developed by Facebook in 2012. Contrary to REST architecture, GraphQL is not an API specification; it’s a runtime for fulfilling queries with existing data. Backbend GraphQL provides a type system that describes a schema for data; in return, this gives front-end API consumers the ability to request the exact data they need.
Web developers utilize REST APIs where data entities live on several URLs on a server. Contrary to multiple URLs and entry points of REST APIs (see Figure 2), GraphQL has a single entry point (see Figure 1). Data is fetched by describing it with a syntax that mirrors its return shape in JSON.4
Figure 2: Representation of REST API
Top 4 advantages of GraphQL
GraphQL can provide customers with the exact data they need. One of the most common problems with traditional REST APIs is that they tend to cause overfecthing, obtaining more information than needed. A REST query will extract all the data from a specific resource, while GraphQL will only get what is dictated in a query (see Figure 3).
Figure 3: Rest API query vs. GraphQL query
GraphQL can process customized queries which contribute to enhanced performance. Processing customized queries reduce the number of API calls.
Contrary to REST, GraphQL has a single endpoint, it is much more predictable, and there is a lower chance of unnecessary API calls. Research shows that mitigating GraphQL from REST increases performance by 66%7of the applications.
GraphQL allows its user to integrate multiple systems, and it can fetch data from existing systems. This allows GraphQL to be utilized without needing to uninstall existing infrastructures, and it can work with existing API management tools.
4. Less effort to implement
Due to the simplified use of GraphQL, implementing queries requires less effort than REST. Research shows that when executing remote service queries, GraphQL is less time-consuming than REST, with a difference of 9 vs. 6.8
Top 4 disadvantages of GraphQL over REST
1. Single endpoint bottleneck
Research shows that GraphQL performed below its REST counterpart for workloads above 30009requests due to endpoint bottleneck disadvantage.
While a single endpoint is one of the strengths of GraphqL, it can become a bottleneck in certain circumstances. HTTP’s built-in cache function in REST APIs produces faster results than GraphQL in almost every scenario. This is because REST APIs’ multiple endpoints allow them to use HTTP caching to avoid reloading resources. GraphQL’s single endpoint pushes the user to rely on an additional library.
REST’s vast popularity and authentication methods make it a better option for security reasons than GraphQL. While REST has built-in HTTP authentication methods, GraphQL does not provide a specific process to ensure security. The user must figure out their own security methods, whether authentication or authorization. However, users can overcome this issue with a well-planned security plan for using GraphQL.
While GraphQL offers a caching mechanism, the cache-implementing process is much more complex and time-consuming than REST implementation. This is due to REST’s advantage by allowing the user to access resources with URLs.
One of the significant drawbacks to using GraphQL is that it is more difficult to specify the API rate limit than REST. This creates the risk of the cost of queries being unexpectedly large, leading to computation, resource, and infrastructure overload.10
To overcome such risks, the user must calculate a query’s cost before executing it. However, calculating GraphQL’s queries is challenging due to its nested structure. Thus, it is best to use a machine-learning approach to estimate.
What are the similarities between GraphQL and REST?
Both are used to create web APIs to allow for communication between clients and servers, allowing applications to access, modify, and manage data in various backend systems.
Just like REST, GraphQL operations are stateless. This means that each request from a client to the server must contain all the information needed for the server to understand and process that request.
By default, both can use HTTP as a transport layer. GraphQL typically POSTs requests, even for fetching data, whereas REST uses a variety of HTTP methods (GET, POST, PUT, DELETE, etc.) based on the type of operation. However, both are sent over the standard HTTP protocol.
Both typically (but not always) use JSON as the format for request and response bodies. This provides a human-readable, standardized data interchange format.
Both are commonly used for web-based applications and services, with libraries and frameworks available in various languages for both client and server sides.
Although strategies might differ, both GraphQL and REST deal with the challenge of versioning, which refers to evolving an API over time without disrupting existing consumers.
7-Middleware & Extensions
Both allow for middleware or extensions that can be used to add additional functionality, such as logging, caching, authentication, and more.
8-Standards and Specifications
Both have formal specifications and best practices. REST is based on the principles laid out by Roy Fielding in his doctoral dissertation, while GraphQL has its specification maintained by the GraphQL Foundation.
Both can be cached, though the strategies and considerations might differ. RESTful endpoints can be cached at the URL level, while GraphQL requires more nuanced approaches given its flexible query structure.
Both require careful consideration regarding security. Authentication, authorization, input validation, and other security practices are relevant for both REST and GraphQL APIs.
Can you use both REST and GraphQL over the same API?
REST and GraphQL can be used in the same application and over the same API. In certain situations, doing so can be beneficial, especially during transitions or when different client use cases exist. Here are 10 things to consider before implementing them:
- Separate Endpoints: Usually, you would have different endpoints for REST and GraphQL. For example, you might have
/api/v1/for your REST endpoints and
/graphqlfor your GraphQL endpoint.
- Shared Logic: The underlying business logic, data retrieval, and manipulation can be shared between REST and GraphQL resolvers/controllers. This ensures consistency across both types of endpoints.
- Transitioning: If you’re transitioning from a REST API to GraphQL (or vice versa), you might maintain both endpoints for a period to ensure backward compatibility. Over time, as clients migrate, you can deprecate the older style.
- Different Use Cases: In some scenarios, a REST endpoint might be more straightforward for certain operations, while GraphQL might be preferred for more complex, variable data retrieval tasks. For instance, a simple health check endpoint might be better suited as a REST endpoint.
- Middleware and Security: Ensure that shared middleware, like authentication and authorization, can be applied consistently to both REST and GraphQL endpoints.
- Performance and Caching: Be aware that caching strategies might differ between REST and GraphQL. RESTful endpoints can be cached at the URL level, while GraphQL might require more fine-grained approaches due to its flexible query structure.
- Documentation: If offering both REST and GraphQL, ensure that documentation is clear about which endpoints are available in each style and any differences in behavior or data between them.
- Development Overhead: Remember that maintaining both can mean extra development and testing overhead. Any changes might need to be mirrored across both, depending on the nature of the change.
- Client Libraries: If you’re developing client libraries or SDKs, you might need to offer versions that support both REST and GraphQL, or clearly document the differences.
- Error Handling: Error handling might be different between the two. GraphQL has its own error format and handling strategy, while REST often uses HTTP status codes.
Next to Read
Your email address will not be published. All fields are required.