6 Months Of Using GraphQL

Having worked on a project for 6 months using GraphQL on the backend, I weigh up the technology’s fit into the development workflow

This article is in no way a comparison of GraphQL with the REST. There are plenty of articles where it is available in great detail. I am going to share my experience using the framework and how it affected our development speed and collaboration between teams.

First and foremost

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API as well as gives clients the power to ask for exactly what they need and nothing more. 

It was developed by Facebook as an internal solution for their mobile apps and was later open-sourced to the community. Ever since then, it has been widely popular among developers and has become a favorite solution for building services.

How does it fit?

1. Pragmatic Data Exchange

With GraphQL, the query can be defined for the fields which the client needs, nothing more and nothing less. It’s really that simple. If the frontend needs a first name and age of a person, it can only ask for that. The last name and address of the person would be not be sent in the response.

2. Using Dataloaders to Reduce Network Calls

Although Dataloaders are not a part of the GraphQL library itself it is a utility library that can be used to decouple unrelated parts of your application without sacrificing the performance of batch data-loading. While the loader presents an API that loads individual values, all concurrent requests will be combined and presented to your batch loading function. This allows your application to safely distribute data fetching throughout your application.

An example of this would be fetching bank details of the person from a different service called as transaction service, the backend can fetch the bank details from the transaction service and then combine that result with the first name and the age of the person and send the resource back.

3. Forget about versioning of APIs

Versioning of APIs is a common problem and generally, it is fairly simple to solve by adding a new version of the same APIs by appending a v2 in front of it. With GraphQL the story is different, you can have the same solution here but that is not going to go well with the spirit of GraphQL. The documentation clearly states that you should evolve your APIs meaning adding more fields to an existing endpoint would not break your API. The frontend can still query using the same API and can ask for the new field if needed. Pretty simple.

This particular feature is really useful when it comes to collaborating with the frontend team. They can make a request to add a new field that is required because of the design change and the backend can easily add that field without messing with the existing API.

4. Independent Teams

With GraphQL, the front-end and back-end teams can work independently. With the strictly typed schema that GraphQL has, the teams can work in parallel. Firstly the frontend team can easily generate a schema from the backend without even looking at the code.

The schema generated can directly be used to create queries. Secondly, the frontend team can continue working with just a mock version of the API. They can also test the code with it. This gives the developers a pleasant experience without stalling their development work.

Yet Not For Everyone

1. Not all APIs can be evolved

Sometimes there would be change from trickling down from the business or design which would require a complete change in the implementation of an API. In that case, you would have to rely on the old ways to do the versioning.

2. Unreadable code

As experienced multiple times now, the code sometimes can become scattered into multiple places when using Dataloaders to fetch the data and could be then difficult to maintain.

3. Longer response times

Since the query can evolve and become huge, it can sometimes take toll on the response time. To avoid this, make sure to keep the response resources concise. For guidelines have a look at the Github GraphQL API.

4. Caching

The goal of caching an API response is primarily to obtain the response from future requests faster. Unlike GraphQL, caching is built into in the HTTP specification which RESTful APIs are able to leverage. And as mentioned earlier a GraphQL query can ask for any field of a resource, caching is inherently difficult.