1 Origin of the problem

It’s worth exploring what went wrong with our Node service, why it happened, and why GraphQL was needed to solve these problems. Next, I will start from the service architecture, briefly introduce the project background, and then through several cases, let you understand more vividly how our current problems arise.

1.1 Introduction to Service Architecture

1.2 Case 1: Difficulty in data customization

As we all know, our services were originally designed based on THE PC terminal. With the development of The Times, various terminals of the mobile terminal become increasingly rich, including the current APP, small program, touch and so on. So without the split service, we are doomed to an evolution of multi-endpoint adaptation. A typical example of this is that the requirements of the same interface may be different at different ends. Take our hotel system for example:

For the hotel list page display:

On the PC and APP end I can put a lot of information on the list of hotel, each hotel will contain relatively complete hotel model field, however, in some cases, such as small program under this scenario, every hotel only show pictures, may I need quotation, name three fields, the client the changeful demand is very common, But we all have the same interface.

So, our code on the APP side would look something like this:

hotelInfo: {
    name: "Hotel",
    price:232,
    imgUrl:"img.jpg",
    tags:[{
        name:"Parent-child family"}], score: 4.2, rank:"XX Hotel ranked X"
}
Copy the code

It will return all fields under the hotel model directly to the client.

For the small program side, we need to add a parameter to determine the source of the request is the small program, and then delete the fields that are not displayed in the model separately to achieve this kind of field-level control. The pseudocode is shown below:

if ( source= = ="XIAOCHENGXU" ) {
    hotelInfo.tags = undefined;
    hotelInfo.score = undefined;
    hotelInfo.rank = undefined;
}
Copy the code

Let’s say now that my applet has been modified, my new version may want to show four fields, but my old version still only shows three, and then we have a version control problem.

As a server, we have two options, regardless of the differences between the old and new versions, to return four fields redundantly, which brings the benefit of simple development, but does not subtract, no risk. The alternative is to add code like this:

if ( source= = ="XIAOCHENGXU" ) {
    hotelInfo.tags = undefined;
    if( version <120 ){
        hotelInfo.score = undefined;
    }
    hotelInfo.rank = undefined;
}
Copy the code

In this way, we can ensure that different custom fields are returned for different versions, with the benefit of no redundant data transfer. The downside is obvious: the server code becomes less readable, messy, and less maintainable.

Assuming that the above requirements occur 5-10 times a week and are assigned to different people for development, our field changes are sometimes very frequent. However, the interface documents are maintained manually by Wiki or YAPI at present, which makes it difficult for us to ensure that these students update the interface documents in time. Services and documents create many differences that are hard to track.



For the students on the client side, the inconsistency between the documents and the real returned data directly leads to the students on the client side may have to repeatedly communicate with the server side, which virtually increases a lot of communication costs, thus reducing the overall efficiency of iteration and development.

From the perspective of the server side, the same interface, for restful architecture, our solution is usually to add judgment according to the demands of the client, and then filter the data on the server side, delete unnecessary fields, or return different values for the same field. Yet because our every hotel field very much, want to go to do such development clearly to server workload has increased a lot, and I’m only a client example here, and all kinds of clients if each have their own special field customization requirements, we are on the server will need to increase the variety of judgment, Then the decision may only be the return of one or two fields, the essence of the operation is virtually the same, but to make the server-side students development more and more difficult and difficult to maintain.

This kind of practice in the PC era, the product iteration relative frequency is low, is enough to cope with, mobile terminal arrival times, however, demand iteration frequency increases, the client types also gradually become more, all kinds of screen adaptation requirements, field customization requirements are different, and each client may also involve a lot of version change. The development efficiency inevitably decreases, and the operation and maintenance difficulty also increases. At the same time, due to the low offline frequency of fields in historical changes, many redundant fields are gradually formed online. When the content of these fields because of version change of documents maintenance and other historical reasons, not in time to make the development team members also dare not easily delete, is always a natural choice to increase the insurance practice fields, over time will form a vicious circle, more and more fields, can be said to return to the body of the redundancy field also brought certain negative influence transmission performance.

The problems summarized in case 1 can be summarized as follows:

• Difficulty in data customization
• Manual Document Maintenance
• Redundant field transfer

1.3 Case 2: Multi-request Stitching

// Method 1: / API /detail {traffic, comment} / API /detailprice {detailprice, detail} / API /clientShow {recommendation} / API /recommendation {recommendation}Copy the code

// Method 2: / API /detail {traffic, comment} / API /detailpriceif( source= = ="APP") {return{Room type, details, guest show, neighborhood recommendation}}return{Room type, details}Copy the code

1.4 Problem Generalization

So, let’s summarize the main problems encountered in the above cases and try to conduct root cause analysis. In project management, some tools (such as fishbone diagram, 5WHY analysis and Pareto diagram) can help us analyze problems intuitively when we find the root cause of problems. If you are interested, you can learn about PMP and ACP, but I will not expand it here. Now I will use this tool to analyze the root causes of our problems.

As you can see, the fish head on our right is the surface problem that we face, and each of these bones reflects one of the main causes of the problem, which may be at different latitudes.

Such as operational difficulties at present, our project development efficiency is low, the problem of performance degradation, it may be due to the interface documents, version control, multiple request design, redundant data in these aspects, and then we found that these problems are based on a restful interface design specification, constantly demand iteration, The gradual and inevitable problems arising from numerous client page changes can be regarded as the problems of restful interface design itself. In other words, the root cause of these problems is the need to find a better interface design paradigm.

2 Scheme Analysis

2.1 GraphQL profile

In 2012, Facebook started working on a technical solution called GraphQL to solve the problem of server feeding mobile data efficiently. In fact, the background of their project is very similar to the process we are facing, that is, the service started from PC terminal, with the popularity of mobile terminal and increasingly rich demand changes, the efficiency of traditional restful design decreased, they want to solve the efficiency problem, so they made this plan. The difference is that Facebook directly developed the standard early on, and over the years they have perfected the model. And we as learners, or need a change in the process of thinking.

So how do you understand GraphQL?

GraphQL is an API query language and a runtime for implementing data queries, or just a specification. It is usually based on the Http protocol.

What is GraphQL? How does it fit into our already somewhat overburdened system? How did he change our development model?

2.2 a Restful to GraphQL

2.3 Implementation of GraphQL

Let’s take a look at how the GraphQL specification fits into our existing system and solves the problem.

The first step is to define the schema.

In order to simplify the problem, we still take the hotel model of the hotel system as an example. The following figure shows the object of hotel information. The SDL language we use to define schema is very simple.

hotelInfo:{
    name: "Xx hotel",
    price:232,
    imgUrl:"img.jpg",
    tags:[{"name":"Parent-child family"}], score: 4.2, rank:"XX Hotel ranked X"
}
Copy the code

Here’s how this model looks abstracted to GraphQL’s SDL:

type Hotel {
    name: String!
    imgUrl: String!
    price: Int!
    tags: [Tag]
    score: Float
    rank: String
}
 
 
type Tag {
    name: String!
}
Copy the code

As you can see, the process of defining a schema is a view-model integration process.

Step 2, write a resolver parser.

This step is fairly straightforward. Once we have defined all the fields and types of the view model that serve the business on the server side, we naturally need to write a method for getting this data. This step for the already existing services actually very simple, you only need to indicate in the resolver you define where access to the data in this model, and the data access method, asynchronous functions, can be calculated using synchronization function, read from the cache, the read database, called tripartite API. You can say that GraphQL is doing an aggregation job here, aggregating more upstream data, maybe micro-services or restful services, in the GraphQL layer. A pseudo-code for Reslover:

hoteReslober:( id: String ) => {
    return db.getHotel(id);
}
Copy the code

The third step is to change the client’s request mode.

For the client, that is, the caller, the biggest change is that we are no longer required to passively process the data returned by an interface, and no longer face the problem of over-fetch and under-fetch. We just have to describe exactly what we want on this page, and then focus on data processing, view construction.

Here is an example of a query on the APP side:

query: hotel (id: String ) => {
    name
    imgUrl
    price
    tags{
        name
    }
    score
    rank
}
Copy the code

2.4 Practical transformation process of GraphQL

2.5 Some problems seen in practice

While GraphqQL has all of the above advantages, we all know that there is no silver bullet, so let’s take a look at some common GraphqQL development problems.

• It increases the difficulty of back-end system design

Traditional restful APIS are more concise and clear for system designers, and the responsibilities of each endpoint are very clear, reducing the interdependence and interference of each module. Therefore, in the system design of GraphQL, special attention should be paid to the coupling between modules, instead of mixing all modules together. This raises certain difficulty to the design. As an existing system, you can design the relationship between view models in a purely restful style at migration time, allowing GraphQL to inherit the benefits of restful.

• Whether there will be back-end performance issues

Performance issues are one of the biggest concerns and concerns on the back end. Will there be additional database queries? How to optimize query performance? All of these present optimization and design challenges. If you’re in the middle tier of Node like us, you don’t have to deal with this problem, leaving the optimization of the database itself to services further back to avoid SQL penetration.

• Costs of migration

For large systems that already exist, how can migration be accomplished, and do language changes need to be made? Do you need to change the framework? How to smoothly implement the migration? These are the direct costs we are facing. How to realize the transformation with the lowest cost and risk is the problem we need to focus on.

• Security issues

Because the client has a very free way to query, so the server is no longer directly control the return field, but need to restrict the requestor some such as query depth, query page limit, etc. As for security, since it is slightly different from restful, designing a more secure and reasonable request scheme is also worth thinking about. The scheme we currently use will not be expanded here.

In general, it is not necessary to use GraphQL to completely replace restful apis. In many cases, it is possible to use GraphQL to call restful apis.

3. Practical value of the company