Since the introduction of Facebook to the digital world, GraphQL has taken the API landscape by storm. As an alternative to REST APIs, GraphQL has gained more popularity than expected. GraphQL fixes many issues that API developers and users have faced with the REST architecture. Although handy, GraphQL API explorer has introduced some challenges that need evaluation. As GraphQL is not a simple replacement for REST. We will look into all pros and cons of each of the API architectures and places where GraphQL made application development easier.
History of REST
Before REST was introduced to the API world, other API integrations like RPC, SOAP, COBRA, and other less open protocols ruled the market. Many pre-REST APIs needed complex client libraries to serialize and deserialize payload over the wire.
A functional difference between REST APIs and SOAP is the strongly-typed formal contact used through WSDL (Web Service Description Language). Since removing the 32-bit integer restriction to accept 64-bit, it could have wreaked havoc on the interoperability, which meant breaking upstream clients. SOAP is a full protocol implementation and not an architecture. It consists of security, error handling, ACID transactions, etc. some of the complexities in SOAP are due to the abstraction layers baked into it.
For instance, SOAP can run on HTTP, TCP, UDP, and other architectures. Simultaneously, the protocol implementation of SOAP is much of the abstraction, the application and data layer’s rigidity contracts between the client and server. This creates a tight coupling between the two layers.
REST architecture was introduced in 2000. It was introduced as a more straightforward way to enable a machine to machine communication using only HTTP protocols and avoiding the additional layers in a stateless and type freeway. This provided systems to be coupled loosely and offer a forgiving contract change between plans like it is stated between companies.
Read more: GraphQL: The Future of Enterprise Software and API Development
REST Today
REST has become the standard for deploying APIs and launching developer platforms for several companies. The most significant advantage of using REST is that full time developers working with third-party APIs do not need any specialized libraries or initializations. You can simply send the requests via cURL or web browsers.
REST uses the standard CRUD HTTP verbs (GET, POST, PUT, and DELETE) to leverage HTTP conventions. It allows REST to center around data resources (HTTP URIs) while not having to fight HTTP.
An eCommerce with a resource “api.acmestore.com/items” can have similar behaviors as the resource “api.examplebank.com/deposits” of a bank.
Both of the resources require CRUD operations and have preferred cache queries, which means that both “GET api.acmestore.com/items” and “|GET api.examplebank.com/transactions” would be cached.
3rd party developers to a new API need to reason the data model and leave the development and functioning to the HTTP conventions without digging deeper into thousands of operations. Although REST has a tighter coupling of HTTP and CRUD to SOAP, it provides lose data contracts.
Problems with REST
With the increasing number of APIs being placed in production and scaled to extreme levels, several REST architecture problems have come to the surface. In a fair comparison, GraphQL stands between SOAP and REST and takes parts of each API architecture, providing a better function.
- Server Driven Selection
In REST APIs, the server creates the representative of any resource to respond to the client.
If the clients wants specific details on certain return names, with rest you might have something like:
GET api.example.com/users/123?include=friend.friend.name&friend.friend.ocupation=engineer
With the advancements of GraphQL, it provides a cleaner way for the query, like:
{
user(id: 123) {
friends {
friends(job: “engineer”) {
name
}
}
}
}
- Fetching Multiple Resources
There are several APIs that provide the ‘GET /user’ first and then fetch each individual via the “GET /user/:id/friend/:id” endpoint. It can result in an N+1 query, which can provide a severe time complexity problem slowing down the API function. In simpler words, REST API calls are chained on the client before that final representation of the query can be displayed. GraphQL reduced the chances of time complexities by providing the server to aggregate the data for the client in a singular and straightforward question.
- In-Depth Analytics
While API analytics is a negative for GraphQL API, there is a minimal scope of tooling. The tools that can support GraphQL API can provide a more comprehensive insight into queries compared to any REST API.
Problems with GraphQL
- Caching Caching is a built-in function of HTTP specification which REST APIs can leverage. GET vs. POST semantics related to caching is a well-defined structure that enables browser cache, intermediate proxies, and server frameworks. The following guidelines are followed in caching:
- GET requests can be cached
- GET requests can stay in the browser history
- GET requests can be bookmarked
- GET requests are idempotent
GraphQL in 2021 does not follow the HTTP specifications for caching and uses a single point architecture. It enables the developer to decide the caching implementations correctly for non-suitable queries that can be cached.
The correct key that is used for caching may include inspecting the body contents of the entire code. While you can use tools like Relay or Dataloader to compile the GraphQL semantics, it still does not cover things like browser or mobile caching.
- Query Rigidness
GraphQL removes the ability for customized query DSLs or side effect operations on top of an API. Although the Elastic search API is RESTful, it has a very powerful elastic search DSL to perform advanced aggressions and metric evaluations. These aggregation queries can be harder to model in a GraphQL API explorer architectural language.
Conclusion
GraphQL APIs can be an exciting piece of advanced technology, but it is essential to understand that compromises are to be made before any architectural decision. Some APIs such as these have very few abilities and relationships across other entities like analytical APIs and may not suit GraphQL.
For applications that delve into various domain objects like eCommerce that include several items like users, orders, payments, and other architectural API Integration Services requirements, it can be easy to leverage GraphQL in a better way.
Comparing GraphQL with REST is like comparing SQL technologies with NoSQL. There are specific applications where it makes sense to model complex entities in SQL databases. Other applications that only include messages, like chat applications or analytical APIs, require single entities like “events” to use Cassandra.
