6 Months Of Using GraphQL

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.