GraphQL may be a better option but should you switch?

Photo by bruce mars on Unsplash

Ivan Sutherland, an Internet pioneer, said, “It’s very satisfying to take a problem we thought difficult and find a simple solution. The best solutions are always simple.”

REST or Representational State Transfer is a living example of this.

Back in the 1990s, there was no uniform way of standardizing web design choices and APIs.

An elegant yet simple solution was the need of the hour.

That’s exactly what a group of experts, under the leadership of Roy Fielding, came up with. We know it as REST APIs.

Fielding summarized the problems that inspired him to build REST:

“I had comments from well over 500 developers, many of whom were distinguished engineers with decades of experience, and I had to explain everything from the most abstract notions of Web interaction to the finest details of HTTP syntax. That process honed my model down to a core set of principles, properties, and constraints that are now called REST.”

But like with everything in the world, with time, there are better replacements.

GraphQL has deservedly gained a lot of popularity recently as it gives good competition to REST.

GraphQL's primary advantage is it provides clients with the ability to define the structure of the data they require and the response from the server is defined in the same structure.

This prevents redundant data to be transmitted from the server for no reason.

However, this is not another blog encouraging you to switch from REST to GraphQL blindly.

I will attempt to explain the shortcomings of REST and how GraphQL can overcome those and if those shortcomings are worth abandoning REST will be discussed.

Why REST is so popular even after 20 years since its birth?

As stated above, REST was the result of the chaos caused by the lack of a uniform & standardized process of building APIs.

But that was in the year 2000.

Over 2 decades later and people still rely on REST APIs because it provides many advantages:

#1. Scalability: REST API is scalable. But what does that mean? They are stateless. Every call to REST API is an independent, separate call.

This enables you to cache responses. REST also allows you to separate the client and server-side codes. Using Redis can greatly enhance your site speeds.

You can make a frontend in Vue and use REST APIs made using Django on the backend and it would work fine.

This decoupling helps in managing codebases.

#2. Flexibility: REST allows developers to structure data as per their needs and the client knows what structure of data to expect.

By giving developers the freedom to structure, these APIs can handle various forms of requests & consequently send data in many formats. Thus the same API can be used for web as well as native apps.

Moreover, this enables you to use many third-party APIs as well, by just simply seeing their sample data responses, and the best part is you probably don’t have to manage any of these third-party APIs. 7 Free APIs That Nobody Is Talking About Create unique and interesting apps using these APIsjavascript.plainenglish.io

Shortcomings of the REST APIs

If REST APIs were impeccable, the popularity that GraphQL received would not be close to what it is today.

In the case of REST, one of its advantages is also its disadvantage.

Under or over data-fetching is the core disadvantage of using REST.

Since REST gives developers the choice to structure data, it consequently removes the freedom of clients to define the structure of data they require.

For example, consider you have a website and a mobile app, both sharing the same API.

The API sends URLs of different sizes of a single image to both web and the mobile app. The web app utilizes the URL of the largest size of the image while the mobile app does the same but with the small size of the image.

URL of the smallest size of the image is not suitable for the web app and the opposite is true for the mobile app.

If only there was a way to tell the API exactly what you…

This is where GraphQL comes into play.

So GraphQL is better than REST?

The answer is not a simple yes or no.

As the name suggests, GraphQL is a query language that gives the ability to clients to define the structure of the data they require, it does have its shortcomings.

The two major ones I encountered were caching and lack of rate-limiting.

Let’s go over this two one-by-one:

Caching: It is not impossible to cache in GraphQL but implementing it is not as straightforward as doing so in REST.

This is because every query can be different whereas with REST, the ‘query’ is the same and we know exactly what to cache.

However, most GraphQL libraries provide a caching mechanism.

Rate-limiting: Again, not impossible to implement but rate-limiting is not something that GraphQL enthusiasts can boast about.

Lately, there have been many YouTube videos and discussion forums where rate-limiting GraphQL is discussed and you can look into those.

Should you switch to GraphQL from REST or vice-versa?

Both of them have their own shortcomings and advantages and there is no universal answer here.

It all boils down to your app and personal preferences.

Below are some points you should consider while choosing either of these APIs:

1. Caching: If caching is an important aspect and you need it very often, then REST is the way to go. However, if only some parts of the site need to be cached, GraphQL can be used to implement such a caching mechanism.

2. Data Fetching: REST introduces under/over fetching of data problem. If you plan on using the same API across multiple devices and want to have the freedom to allow clients to structure data, then without a shadow of a doubt, GraphQL is the way to go.

3. Decoupling: Whenever the frontend requires new data, say displaying the full name instead of just the first name, they can simply change the query without changing anything on the backend. It helps the backend and frontend team to work independently.

4. Simplicity: If you are a beginner then it’s my advice to learn REST at least as it opens a gateway of opportunities. Moreover, if you’re building a side project that you don’t really see scaling or being just that, a side project, then REST is the preferred choice since it’s easy to implement(unless of course your side-project specifically needs the abilities of GraphQL).

Final thoughts

As a web developer, it brings me joy to see options like REST and GraphQL but at the same, it contributes to the horrors of misplanning big projects and rewriting backend code.

GraphQL and REST have their own list of pros and cons and knowing them beforehand can save you from countless hours of coding & rectifying mistakes.

Choosing any one of these two boils down to your app requirements.

Neither of them is perfect, but they can be a perfect fit for your next app if you think twice before going with either of these.

Thanks for reading!

More content at plainenglish.io