This article is the third in the Full Stack GraphQL + Flutter Best Practices article series. This paper introduces the design concept of GraphQL and its advantages and disadvantages.

What is theGraphQL?

GraphQL is both a query language for the API and a runtime for your data queries. GraphQL provides an easy-to-understand set of complete descriptions of the data in your API, enabling a client to get exactly what it needs without any redundancy, making it easier for the API to evolve over time, and for building powerful developer tools.

Everything is a Graph

Using GraphQL, we can model all of our business as diagrams

Diagrams are powerful tools for turning many real-world phenomena into models because they are similar to our natural mental models and verbal descriptions of basic processes. With GraphQL, we model our business domain into a graph by defining a schema; In our schema, we define different types of nodes and how they are connected. On the client side, this creates a pattern similar to object-oriented programming: types that reference other types. On the server side, since GraphQL defines the interface, we can use it freely on any back end (old or new!). .

The common language

GraphQL is not a protocol or specification. It’s a language, a front-end and back-end communication language. This language uses a concise syntax to reduce the cost of communication between the front and back ends. In addition, the language is very rigorous and readable. This reduces the possibility of misunderstandings in communication and reduces Debug time.

Developers familiar with the language look at the project’s schema and immediately know how to send requests and what format the return values should be. It all took less than two minutes, and the process was done by one person alone, with no need to communicate with the back end.

Demo gold Nuggets APP

Let’s use a page to show how GraphQL is different. Many apps now have a similar front page, with tabs at the top and a list of content under the selected tabs in the middle:

Typically, this page will have two interfaces:

  1. Get all tags – mainly used to display the top TAB bar
  2. Get content list by tag – mainly used to show the list of posts in the middle

When the client first enters the page, it makes two requests, concatenates the results of the two requests, and then refreshes the page. That’s the traditional way to do it.

thenGraphQLHow is this function implemented?

Define a schema:

Query is an entry, and we can retrieve some of the tags using the tags method under Query:

Perform:

This is also the first “get partial label” interface mentioned earlier.

Let’s look at how the second interface, “Get a list of blog posts by tag”, is implemented.

We can use the tag method under Query to get the tag, and then use the posts method under tag to get the corresponding list of posts:

So we can call the two interfaces separately.

One more thing!

Additionally, GraphQL can retrieve both resources in a single request:

Good Job!

However, there is still a problem, which may have been found by careful students, that is:

Information about the author of the blog is missing, and the USERNAME and avatar URL are not returned. Let’s fix it now by pulling the information from the user field under Post:

Done!

The lines

If we had a page called All Tags. In addition, this page also previews the first 4 blog posts under each TAB. How do you do that?

reflection

Many pages today need to send requests to multiple resources. Some pages may send more than three requests, and there may be dependencies between the requests, that is, the latter request depends on the results of the previous request.

If we use GraphQL, as long as the schema is properly designed, the number of requests to a page can be reduced by at least half, and there is no need for the back end to create a separate custom interface for the page.

Because GraphQL request configuration is so flexible, we can compose a variety of requests ourselves through the definition of the schema. This also reduces the workload on the back end to some extent. In the middle and later stages of the project, we will find many new requirements, which do not need to separate the interface, just reuse the previous interface. For example: the need for “all tags + preview tags” mentioned in the above.

GraphQLadvantage

  • Ask for the data you want, no more, no less
  • Save bandwidth
  • API evolution does not require versioning
  • A robust type system
    • Automatic document generation
    • Reduce communication costs at the front and rear end
  • tool
    • Graphiql-graphql Playground
    • Code Generater – The front end (Web and native mobile) generates the request Code, and the input and return values are strongly typed

GraphQLdisadvantage

  • Learning costs because of the need to learn a new language GraphQL
  • Teamwork mode changes
  • The front-end pressure is lower, but the server pressure is higher because some of the front-end pressure is transferred to the server
  • Getting data is less efficient and requires optimization with tools like Dataloader

Who is using GraphQL?

  • GitHub
  • Twitter
  • Pinterest
  • PayPal- Scaling GraphQL at PayPal
  • Netflix – Our learnings from adopting GraphQL
  • The New York Times – The New York Times — Now On Apollo
  • Nerdwallet – Getting started with GraphQL and Apollo (Part 1)

reference

GraphQL

schema

Thoughts about Graphs