Comparison Between GraphQL and REST

REST compared to GraphQL

The creators of GraphQL designed it with a focus on flexibility and performance. As a result, it resolves many of the inherent flaws and inefficiencies that developers encounter when communicating with REST APIs.

To understand the differences, let’s take a closer look at the pizza application we mentioned in this previous section. A pizza application needs to display the available pizza toppings, sizes, and upgrades.

Let’s see how this scenario would be handled by both REST and GraphQL.

Using REST API

In REST APIs, we populate the data by accessing multiple API resources from various endpoints. We also need to fetch /pizzas/toppings to return all the available toppings. After that, we need /pizzas/sizes to return a list of available pizza sizes.

Using GraphQL

In GraphQL, the server can respond to multiple data requests that the client defines in the query.

Benefits of using GraphQL

Here are some benefits of using GraphQL:

No more over/under-fetching

A common problem with REST is over-fetching and under-fetching. The server always returns fixed data structures, so the client can’t adjust data to their needs.

Over-fetching

Over-fetching means that a client downloads more data than the application requires.

Imagine a pizza application that only needs to display a list of pizzas with images.

The application would need to fetch the /pizzas endpoint in REST API. The application might receive more data than it needs (timestamp, pizza availability). The extra data is probably unnecessary since it only needs to display the images of the pizzas.

Under-fetching and the n+1 problem

Under-fetching means an endpoint doesn’t provide enough data. Without a good API design, the client will be the one who ends up making additional requests to fetch everything they need.

When the client needs to get a list of items but the initial request lacks the needed data, the client must make another request.

What if our pizza application needs to display the three most popular pizza toppings? The server would need an additional endpoint called /pizzas/<id>/toppings/popular to display the required information.

Flexible APIs

In REST APIs, it’s common to organize our API’s endpoints according to the screen of our application. By simply calling the relevant endpoint, the client may retrieve all essential information for a certain view.

The drawback of this method is that it doesn’t allow for quick frontend iteration. Every time we iterate on the user interface, there’s a chance we’ll need more or less data than before. As a result, the backend must be updated to accommodate the additional data requirements. It will be difficult to iterate on the frontend without a robust API design.

Clients control the data needs, meaning that any change on the server that doesn’t break it may be performed without additional effort.

Insightful & rich data

GraphQL allows us to go into greater detail in particular fields or even deprecate sections that clients no longer need. It’s simple to perform low-level performance monitoring of processed requests using GraphQL. To handle the requested data, GraphQL employs resolver functions. Measuring the performance of these resolvers may reveal critical information about our application’s bottlenecks.