How to Use GraphQL: How to Use GraphQL

Learn why GraphQL is a more efficient and flexible alternative to REST apis. With a strong typing system, the front-end problems of over-fetching and under-fetching are avoided.

Basic and advanced series translations have been completed:

  1. introduce
  2. GraphQL has advantages over REST
  3. The core concept
  4. architecture
  5. The client
  6. The service side
  7. More concepts
  8. Tools and Ecology
  9. security
  10. Q&A

Over the past decade, REST has become the standard (albeit vaguely) for designing Web apis. It offers some great ideas, such as stateless services and structured access to resources. However, REST apis are too flexible to keep up with the rapidly changing needs of clients.

GraphQL was developed to meet the need for flexibility and efficiency! It addresses many of the drawbacks and inefficiencies that developers encounter when interacting with REST apis.

To illustrate the main differences between REST and GraphQL when extracting data from an API, consider a simple example scenario: in a blog, an application needs to display the post title of a particular user. The names of the user’s last three followers are also displayed on the same screen. How do REST and GraphQL solve this situation?

💡 Check out this blog to learn more about why developers love GraphQL.

REST vs GraphQL for data acquisition

Using REST apis, it is often possible to collect data by accessing multiple endpoints. In the example, it could be the/Users /< ID > endpoint that gets the initial user data. Second, there might be a /users/

/posts endpoint that returns all of the user’s posts. Then, the third endpoint will be /users/< ID >/ Followers returns a list of followers for each user.

With REST, you have to make three requests to different endpoints to get the data you need. This can also lead toOverfetchingBecause the endpoint returns additional information that is not needed.

In GraphQL, on the other hand, a single query containing specific data requirements is sent to the GraphQL server. The server then responds with a JSON object that meets these requirements.

With GraphQL, the client can be accessed inqueryTo specify exactly what data is required. Note that the server responds to theStructureIt follows exactly the nested structure defined in Query.

Don’t get too much or too little data

One of the most common problems with REST is over-and underfetching. This happens because the only way for a client to download data is to access an endpoint that returns a fixed data structure. It is very difficult to design an API that meets the exact data needs of the client.

“Think in graphs, not endpoints.” Lessons From 4 Years of GraphQL by [Lee Byron] (twitter.com/leeb), Co-creator of GraphQL.

Excessive fetching of data

* Overfetching * means that the client downloaded more information than the actual requirement of the application. For example, suppose you have a screen that only needs to display a list of users with their names. In REST apis, this application typically accesses the/Users endpoint and receives a JSON array with user data. However, this response may contain more information about the returned user, such as their date of birth or address, which is useless to the client because it only needs to display the user name.

Insufficient data acquisition and N +1 problems

Another problem is underfetching and N +1 request problems. Underfetching usually means that a particular endpoint cannot provide enough of the required information. The client will have to make additional requests to get all the data it needs. This can escalate to a situation where the client needs to download the list of elements first, but then needs to make an additional request for each element to get the required data.

For example, given that the same application also needs to display the last three followers for each user, the API provides additional endpoints /users/

/followers. To be able to display the required information, the application must make a request to the/Users endpoint and then access the/Users /

/ Followers endpoint for each user.

Rapid production iterations at the front end

A common pattern for REST apis is to construct endpoints based on views within the application. It is convenient because it allows clients to obtain all the necessary information for a particular view by simply accessing the corresponding endpoint.

The main disadvantage of this approach is that it does not allow rapid iteration at the front end. With each change to the UI, there is now a high risk that you will need more (or less) data than before. Therefore, the back end also needs to be adjusted to address the need for new data. This reduces productivity and significantly reduces the ability to integrate user feedback into the product.

Using GraphQL, you can solve this problem. Because GraphQL is so flexible, changes can be made on the client side without any extra work on the server side. Because the client can specify the exact data requirements, there is no need for back-end engineers to adjust when the design and data requirements of the front end change.

In-depth analysis of the server side

GraphQL provides a deeper insight into the data being requested on the server. Because each client specifies exactly the information of interest, you can gain insight into how the available data is being used. For example, this can help improve the API and discard any specific fields that the client no longer requests.

Using GraphQL, you can also do low-level performance monitoring of requests being processed by the server. GraphQL uses the concept of resolver functions to collect data from client requests. Monitoring the performance of these parsers can provide critical analysis of system bottlenecks.

Benefits of schema and strongly typed systems

GraphQL uses a strongly typed system to define the functionality of the API. Use the GraphQL Schema Definition Language (SDL) to write down all types exposed in the API in the schema. This schema acts as a contract between the client and the server to define how the client accesses the data.

Once the schema is defined, the front-end and back-end teams can work without further communication because they both know the definite structure of the data sent over the network.

Front-end teams can easily test their applications by mocking the data structures they need. When the server is ready, you can turn on the client switch to load data from the real API.

Front-end notepad, not regularly updated, welcome to pay attention to!

  • Wechat official account: Lin Jingyi’s notepad
  • Blog: Lin Jingyi’s notebook
  • Nuggets column: Lin Jingyi’s notebook
  • Zhihu column: Lin Jingyi’s notebook
  • Github: MageeLin