History of GraphQL

I started using GraphQL in my work. As usual, I was curious about the history of GraphQL, so I looked into it.

References.

https://www.youtube.com/watch?v=VjHWkBr3tjI

Lee Byron, co-creator of GraphQL and Executive Director of the GraphQL Foundation, gives an introduction to the history of GraphQL.

The following documents are also useful.

• https://dev.to/tamerlang/a-brief-history-of-graphql-2jhd
• https://levelup.gitconnected.com/what-is-graphql-87fc7687b042

Before GraphQL was created

A brief summary of the history of GraphQL before it was born.

Three challenges of developing with the REST API

We faced three challenges when developing with the REST API

• Slow on network
  • Not all the data we needed was returned from a single API, so we had to make multiple requests back and forth.
• Fragile client/server relationship
  • API changes had to be carefully passed on to the client code or it would crash.
• Tedious code & process
  • Client development is very tied to the API response, so if the API response changes, the client must change too.

To solve these challenges, FaceBook developed a prototype called Supergraph. The collection of best practices became GraphQL.

Example: multiple requests over and over again

An example of making multiple requests is given on the following page.

• https://www.howtographql.com/basics/1-graphql-is-the-better-rest/

As an example, the case is to retrieve three pieces of information: user information, content posted by the user and the user's followers.

In the case of the REST API, the three round trips would be as shown in the following image.

For GraphQL, data can be retrieved in just one round trip.

From REST API to GraphQL

The switch from the REST API to GraphQL has resulted in the following three benefits

• Fast on network
  • Only one request is needed, as only what is needed can be written
• Robust static types
  • Clients know what data is available and what type it is
• Empowering client evolution
  • The format of the response can be controlled by the client. This makes the server side simpler and easier to maintain
  • Old fields can be deprecated and functionality can continue. This backwards compatibility eliminates versioning management.

Revisiting the three challenges

Three challenges for the REST API, now that we are in the year 2022

• Slow on network
  • In 2012, 3G lines were widespread.
    • Multiple requests and large API payloads will have a significant impact on network latency
  • In 2022, 5G lines are widespread
    • Network latency will not be such a critical issue
    • Of course, if a product has many users with low network latency, it may need to be considered.
  • Could multiple requests be solved by building a BFF-like fuzzer?
• Fragile client/server relationship
  • Versioning and backwards compatibility is still one of the challenges of the current REST API.
• Tedious code & process
  • Can schema-driven development solve the problem?

Although written briefly, the three issues may have been deeper and more difficult to address. But thinking about it in today's world, I wondered if the use case for GraphQL is an edge case. I imagined that one of the root causes of the challenges in this case might be the complexity of data structures (recursive, nested) in news feeds.

Reference links

• https://www.apollographql.com/blog/graphql/basics/why-use-graphql/
• https://wundergraph.com/blog/why_not_use_graphql

GraphQL Appeal.

Data selection

We find GraphQL's ability to describe the data we need attractive. In traditional REST API development design, we have experienced the following patterns in our work.

• Query parameters to group response data variations Response group
  • Response group
    • small
      • Minimum set
    • middle
      • Between small and large
    • large
      • All fields

We have not experienced any major challenges in developing with the Response group. I think the advantage of the API's ease of scaling is in the selection of data.

Data hierarchy

GraphQL allows a hierarchical structure to be expressed in the request and response data. This is also attractive.

With traditional REST APIs, query parameters in a request could only be sent in a flat form. There is also the possibility of sending JSON using the request body. (Well, this is GraphQL).

The ability to express a hierarchical structure in a REST API request seems to be a good and flexible way to show the relationship between data.

However, I personally feel uncomfortable.

Data references are also POST

The REST API uses HTTP GET for references and HTTP POST for updates. GraphQL uses HTTP POST for both references and updates. This is not quite right. I would like to be able to use HTTP GET for queries and HTTP POST for mutations.

Conclusion

This is a brief introduction to the history of GraphQL. I have not used it that much yet, so I would like to understand its good and bad points.

If it was helpful, support me with a ☕!

Share

Related tags