• 6 Months Of Using GraphQL
  • Manish Jain
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: YueYongDEV
  • Proofread by JohnieXu and Cyril

Six months with GraphQL

After six months of back-end project development with GraphQL, I began to wonder if the technology was appropriate for development work.

First of all,

GraphQL is a query language that implements apis and a runtime that uses existing data to complete these queries. GraphQL provides a complete and easy-to-understand description of the data in your API, and gives users the power to decide what they want, but nothing more.

It was developed by Facebook as an internal solution for its mobile application and later opened up the source code to the community.

advantages

Pragmatic data exchange

With GraphQL, you can specify a query for the fields a customer needs, no more, no less. It really is that simple. If the front end only needs a person’s ** name and age fields, simply request the corresponding fields. Other fields such as the person’s last name and address ** are not returned in the request result.

Reduce network calls using Dataloaders

While Dataloaders are not part of the GraphQL library itself, it is a useful third-party library to decouple unrelated parts of your application without sacrificing the performance of bulk data loading. Although the loader provides an API for loading individual values, all concurrent requests will be combined and distributed to your batch loading function. This allows your application to securely distribute and retrieve data throughout the application.

An example of this is getting a person’s bank information from another service called a transaction service, from which the back end can get the bank information and return the result as a result combined with the person’s ** name and age **.

Expose decoupling between data and database models

One of the great advantages of GraphQL is the ability to decouple database modeling data from the data exposed to users. This way, when designing the persistence layer, we can focus on the requirements of that layer and then separately consider how best to expose the data to the consumer. This is closely related to the Use of Dataloader because you can combine data before sending it to the user, making it very easy to expose the design model of the data.

Forget about API versioning

Versioning of apis is a common problem, and often a simple solution is to add a V2 identifier in front of the same API. But once you have GraphQL, things are different. You can still use the same solution, but it doesn’t fit the GraphQL philosophy. The official documentation clearly states that you should improve your API, which means that adding more fields to an existing endpoint will not break the existing API. The front end can still use the same API for queries and can query new fields as needed. It’s a really clever way to handle it.

This feature is very useful when working with the front-end team. They can make requests and add new fields that are needed due to design changes, which the backend can easily add without breaking existing apis.

Independent team

With GraphQL, the front end and back end can work independently. Because GraphQL has a strictly typed architecture, two teams can work in parallel without affecting each other. First, the front-end can easily generate a data model without looking at the back-end code, and the generated data model can be used directly to create data queries. Second, the front end can use apis derived from mocks to test the code. This will not hinder the development of the front and back end, greatly improving the development experience of programmers.

disadvantages

Not all apis can be improved

Sometimes, there are business or design changes that require a complete change in the implementation of the API. In that case, you’ll have to rely on the old ways for version control.

Unreadable code

As it goes through multiple iterations, the code is sometimes scattered across multiple locations when reading data using Dataloader, which can be difficult to maintain.

Longer response time

As queries grow and become bloated, response times can be extended. To avoid this, make sure you have succinct response resources. For guidelines, check out the Github GraphQL API.

The cache

The main purpose of caching API responses is to get responses from future requests more quickly. Unlike GraphQL, RESTful apis can take advantage of the caching built into the HTTP specification. As mentioned earlier, GraphQL queries can request any field of a resource, so caching is inherently difficult.

conclusion

I strongly recommend using GraphQL instead of the REST API. The flexibility offered by GraphQL can definitely replace its pain points. The pros and cons mentioned here may not always apply, but it’s worth thinking about exploring how GraphQL can help you complete your projects.

If you have any comments, please comment below.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.