Why I chose GraphQL for my next project

GraphQL has been a new entry into the world of APIs after the REST API era.  It was released by Facebook in 2015 and hence since slowly being adopted into the mainstream of API development. In this post, I shall write as to why I decided to use GraphQL in my next project.  Please note that this is not a tutorial about GraphQL, it just spins around the thought process of choosing GrapQL over REST  or SOAP.

WH

What is GraphQL?

GraphQL is an open-source query language published by Facebook, that allows you to write queries using object structure rather than a string. GraphQL is a syntax that describes how to ask for data and is generally used to load data from a server to a client. With GraphQL in the arsenal, the frontend developer is able to make a single call to fetch the required information rather than to construct several REST requests to fetch the same.
Just like REST, GraphQL too runs over HTTP, but unlike REST, the developer can choose what data it wants from the backend while using GraphQL.

What is my next Project?

My next project was not actually my personal project. I joined a startup some time back, and this project was the need of the startup. We were trying to build an analytics dashboard for one of our clients.  One thing that straightaway hops into our minds as we talk about analytics dashboards is DATA.
The skeleton of our dashboard was this data. But to make the dashboard more impactful we needed a lot of graphs.
A new graph means a new permutation of data.  Since we had a strict policy of no business logic on the frontend, we had to send a huge chunk of data, in a variety of permutations to the frontend, all this while maintaining our SLA.

Why I chose GraphQL over Rest?

The decision to chose GraphQL over Rest was backed by a lot of research and discussion. Here are some of them, summarised as bullets.

• Saving Multiple Round Trips.

  Each page on the Dashboard has different charts and graphs, and each graph or chart wants data in a separate format. Suppose we were using REST for this, we had to expose numerous APIs to fetch data in all these different formats. We could have reduced the number of APIs but then the business logic would get overwhelmed by if-else/switch statements. To make things simple, we went ahead with GraphQL. Using GraphQL, we can query data for each of these graphs via a single backend call using multiple queries.

• Reducing Redundant data fetch

  Suppose we have a REST API that serves that sends a JSON object with 4 keys. In one of the other graphs, we need just one of those keys. We can either expose a new endpoint that only returns that particular key. Or we can use the same endpoint, but just capture the only key that is required.
  The first option is an absolute waste of effort. It will give a gigantic number of APIs. In the second option, we unnecessarily fetch 3 keys every time we load the page. GraphQL again comes to the rescue. In a GraphQL we define the fields we want in return. Thus it provides No UnderFetching and No Overfetching.

• Strongly Typed Schema

  Again, imagine we were using REST APIs, the number of endpoints would have skyrocketed very quickly. With this, the number of JSON objects that the application can receive and send would have skyrocketed too. We either needed to have very strict Documentation in place or be ready to search the whole codebase to understand a JSON schema. Thanks to the strongly typed feature of GraphQL, we were forces to define the request and response schema for each GraphQL query, with the datatype. Now all our devs know, where they can found the description of all the request-response schema.

• Fetching Data From Multiple Sources

  We needed to fetch some data from SQL, some from No-SQL, and some even from Redis Cache. Again a system of APIs would have either been increased the quantity of APIs or reduce the quality of API. With GraphQL, we divided the fetch from each data source to one query and sent all those queries to the backend at once. Now each query has its own resolver and knows where to fetch data from.

• Ease of Implementation

  Making a system of REST APIs for this analytical dashboard would be cumbersome. So many data fetch so many forms of the same data. Design alone would have taken quite an effort, and coding that design would have taken an eternity. Thanks to GraphQL, we did not need to ponder down to create a separate REST API for each graph, thus could implement the task easily.

Experimentation is a developer’s best friend. If you are not experimenting with new tools and technologies, you are probably designing an application for the past, not the present. We faced a not-so-common use case. We did some research,  inferred a solution, and coded it. This experimentation and inference backed by research is the reason I chose GraphQL for my next project.