Increasingly bloated Web applications

As Web applications become more and more complex, especially those like toB Web applications (such as financial software, ERP and other enterprise software), the traditional front and back end REST architecture interaction scheme greatly limits the software development efficiency and increases the maintenance cost. Not only the front end, but also the back end development and maintenance cost is getting higher and higher.

The main issues with REST architectures are the following:

  1. Excessive data acquisition. For example, sometimes the front-end may obtain the same data on the same interface in order to meet the business requirements on the Web and mobile terminals, but some data is not necessary on both ends.
  2. Front-end business data may have to be obtained through multiple interface requests, and the maximum number of concurrent requests allowed by a browser like Chrome is six, which can be somewhat of an experience issue.
  3. Some REST interfaces are not very standardized, such as query interfaces that have too many data fields and are defined as POST interfaces.
  4. The front-end needs to know the address of each interface service in order to obtain the corresponding resource data.
  5. If the backend API changes, one or more of the other apis may break, and the front end data may be corrupted, even by a simple data structure change, which can be fatal to the front end and will most likely be adjusted.
  6. When new functions need to be developed, the backend needs to aggregate data from multiple microservices for the front end to use.

In addition to the technical issues mentioned above, the front and back ends may also face non-technical problems due to the fact that the REST architecture creates a certain degree of coupling between the front and back ends. After all, the front and back end may see things differently, and REST interfaces may logically affect each other’s emotions to some extent.

To solve these problems, we can build a BFF layer through GraphQL to improve the development efficiency of the front and back ends and reduce the maintenance cost.

What is a GraphQL?

Before introducing what GraphQL can do, let’s look at the concepts and basic components of GraphQL. According to the official website, GraphQL is a query language for apis, a server-side runtime that executes queries using a type system defined by your data. GraphQL isn’t tied to any particular database or storage engine, but relies on your existing code and data to support it.

A basic Graphql service core consists of Query, Mutations, and Schema, which are briefly introduced here.

  1. A simple Graphql Query statement is shown in the following figure:

  1. Mutations are the method used by the GraphQL data platform to modify server data. One Mutations can modify multiple server data, but unlike queries, the query fields are executed in parallel, while changes are performed linearly, that is, one after another. A simple Graphql change statement and change results look like this:

  1. Schema, which describes how to query data through a separate type system (which can communicate with any language, such as Javascript, Golang, Java, and so on), defines GraphQL’s query structure, and its return value structure is very similar to the query structure. Here is a simple Schema definition:
enum Gender {
    Man
    Woman
}

type User {
    name: String!
    age: Int!
    gender: Gender
}
Copy the code

What can Graphql do?

  • Let the interface be typed

Because GraphQL has a strict type system, which is written by GraphQL Schema Definition Language (SDL), Query or Mutations defined by Scheme are both typed, solving the problem that REST interface has no type. Type matching allows you to spot errors early in your interface, making your data more secure.

  • Improve client efficiency

In some business scenarios, the front end needs to obtain the data required by the business by combining multiple REST interfaces, and there may be some redundant data. GraphQL improves the customer’s full request efficiency to a certain extent by reducing network round-trip, request times and data transmission amount.

  • Readable, the code is the document

Through many GraphQL Query tools, such as GraphiQL, the structure and data type of Query or Mutations data can be intuitively understood.

  • You can easily modify data without knowing the ADDRESS of the API interface

The front-end uses REST interface to modify server data, which requires defining URIs and Http methods for asynchronous requests. GraphQL eliminates these steps, and can quickly add, subtract and change the data through Mutations.

Some problems with GraphQL

GraphQl does solve a lot of problems for front and back end interaction, but it should not be ignored that GraphQl has some problems in some scenarios.

  1. The front end should use GraphQL comfortably. Under the existing service architecture, the server side may have to rewrite the way of data exposure, which requires a lot of refactoring to build the interface of composite GraphQL specification, and the risk and cost are high.
  2. GraphQL Query is difficult to do caching, although you can give Query instance an ID to achieve caching, but in real scenarios such implementation is complicated and difficult, there are some performance problems.

The end of the I

Although GraphQL has many problems in some scenarios, and the cost and risk of transforming the existing front and back end interaction mode are huge, it is not recommended to reconstruct the existing complex service architecture. But under the new business scenario, and the continuous powerful GraphQL ecological tool chain will let GraphQL solve many unexpected problems, ecological chain is an important factor to promote GraphQL to improve the market share, but also GraphQL to become a new generation of important technology reasons. Finally, there’s a nice GraphQL online experience where you can actually experience how to manipulate data with GraphQL.