[16] – Can GraphQL solve REST API’s underfetching problem?

In our last blog post, we learned how GraphQL is useful in solving REST API’s Overfetching problem. In this one, lets look at how GrahpQL can also help in resolving problem of Underfetching.

Now before some of the Restofarians (I swear I did not make this one up) accuse me of speaking on both sides of my mouth, hear me out.

Let’s look at our product API example

Say in our database, we store related products information against each of the product, so that when the user is browsing details of a product, we can also show Related Products with it.

Hence, in our backend, for a product, we may store multiple related products id using database normalization methods.

When we retrieve product information using its GET REST API, we see following things

Request (GET)

Result:

Now, we need to display some basic information of related products (like Image and Name). So we need to again make GET calls using the API url used above, but with different id.

So after making a total of 4 requests (1 for product and 3 for related products) we have the information to display ProductDetails page along with Related products. So far so good.

These queries are initiated from client website or mobile apps to server then to backend database and back. So lets say each time we retrieve a product, it takes 500 miliseconds. Hence in above case, we will spend 2 seconds (4 times 500 ms) to get what we want.

Now imagine if each of the related products comes in multiple colors. So there are many SKUs per related product.

Hence our hierarchy for a product looks like the one shown below

In order to fetch all this information to display ProductDetails page, we have to execute following queries.

1. Get Product A details – 1 query
2. Get Product B details – 1 query
3. Get Color names from id for Product B -3 queries
4. Get Product C + Its Color names (4 more queries)
5. Ditto for Product D (4 more queries)

So, 13 queries in total. With each query taking 0.5 secs, that is 7.5 seconds of wait time to fetch information for rendering this page.

This is called the Underfetching problem of REST. For every related information that we require, we have to initiate additional API calls to the server.

Now there can be optimizations and workarounds done, like using Async/Await for parallel execution or creating separate API functions for such scenarios or using parameters etc., but that is like treating the symptoms rather than the actual disease.

So, let’s see how GraphQL can help resolve this issue. By its design, GraphQL works to get you all data that you ask in one go.  Hence if we had to query above product with its related products, our GraphQL query would look like the following

Request:

And GraphQL will give us the following response

If we had to depict the request/response in a picture, it will look like the following

Image credit: www.howtographql.com

This is all done in just 1 query fired from client to API server and back. So, it will not take 6.5 seconds for loading the ProductDetails page but something more than 500 ms (as backend will take some time to aggregate data). Let’s say it takes 1000 ms.

Still 1 sec. of response time is far better than 6.5 secs. Also, think about the additional savings in network data transfer and processing load on your API and Backend servers in servicing 13 queries v/s 1.

Also notice that the shape of response matches exactly with the shape of request. This way, we can ask for data in the form required rather than getting the default returned by REST GET query. There are options to Include or Exclude certain fields based on conditions, which is called Directives. But that is an advanced topic.

This is another area where GraphQL can help significantly improve performance of your APIs.

Happy Clouding!

Advertisement