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 needs a and of a , it can only ask for that. The and of the would be not be sent in the response. frontend first name age person last name address person 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 of the person from a different service called as , the can fetch the from the and then combine that result with the and the of the and send the resource back. bank details transaction service backend bank details transaction service first name age person 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 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. v2 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 can easily generate a schema from the backend without even looking at the code. frontend team The schema generated can directly be used to create queries. Secondly, the 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. frontend team 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.

Facebook

Fetch

Read My Stories

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

6 Months Of Using GraphQL

Too Long; Didn't Read

Companies Mentioned

Manish Jain

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

6 Months Of Using GraphQL

Too Long; Didn't Read

Companies Mentioned

Manish Jain

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES