Experts gather between REST, gRPC and GraphQL!

REST, GraphQL, and gRPC are the three most commonly used ways to organize APIs exposed on the Web.

Whenever I look at these terms, I have a difficult time making a choice. These colorful protocols fill our toolboxes, but they also raise a difficult question: If I want my programs to be healthy and long-lasting, I have to understand what they are.

This is annoying because they are like models of screws and nuts, and all you have to do is pick the right ones from a bunch of parts, match them up, and make them combine to form the function you want.

It's boring and worthless. But for the sake of money, you have to learn it. This article is to help you make a quick choice, without dragging your feet, and get the job done quickly. It's much more interesting to have a cup of tea than to worry about it.

Rest

REST is the most commonly used API interaction method, and SpringBoot has highly integrated it. It uses semantic URLs and the most common HTTP protocol to complete stateless request interactions.

Rest is the abbreviation of Restfull, which uses HTTP's POST, GET, PUT, PATCH and DELETE to define operations on resources.

Although it has such operational significance, in normal use, we are accustomed to only using its POST and GET methods, which correspond to @GetMapping and @PostMapping annotations in Spring. There is no other reason, just because REST seems very powerful, but the curve is relatively high in enterprise development, and many aggregate resources and complex operations cannot be abstracted into resources at all.

But the Rest variant is also Rest, and it is still the most widely used mode.

The reason for choosing Rest is that its ecosystem is so good. From Ruby to Java, from Golang to Rust, there is almost no language that does not support Rest. If you want to develop a Web system, you can easily expose your API with just a few lines of code. Moreover, it is highly integrated with the gateway, and various load balancing components are proficient in HTTP protocols. If you choose it, it will really save you a lot of trouble.

However, REST also means low efficiency. Since it has to be compatible with HTTP1.0, frequent short links also cause a waste of resources. Even for long links, the bloated size of HTTP makes it inferior in the scenario of pursuing high performance. In addition, it is stateless. If you want to pass some data accompanying the user, such as JWT Token, you have to put it in the HTTP Header or Cookie, which increases the overall transmission burden.

In short, REST is a quick start, but in high-performance, stateful scenarios, you have to choose something else.

gRPC

gRPC is of course a product of Google, because the data it transmits is encoded by protobuf, another product of Google. When mentioning gRPC, we have to mention thrift, they are the same thing. But due to the halo of Google, gRPC is more popular.

The development of gRPC is not as flexible as Rest. It requires you to define a contract and then reference and transmit it on both the client and server.

With this contract, data can be compressed. For example, the commonly used json actually has a lot of redundant information. If the fields of json are replaced with fixed ints, or are placed in fixed positions for transmission, then the field names do not need to occupy such a large space.

gRPC provides multiple data transmission modes.

• Similar to the question-and-answer mode of REST HTTP;
• Client-Streaming: The client sends data in a streaming manner, which ends with specific information, and the server returns the result.
• Server-Streaming The client requests the server, and the server continues to send data to the client until it is notified that it has finished.
• Bidirectional Streaming Duplex channel, that is, ordinary TCP link, all in streaming mode;

gRPC has been developed for so many years (2016), and its support for load balancing is also very good. Compared with traditional REST, it uses HTTP2 to transmit data, which reduces the waiting time of question and answer and reduces the connection occupation.

If you are working on the Internet of Things, or collecting data in some weak network environments, this high compression ratio of data will definitely allow you to get twice the result with half the effort. Of course, if your microservice system pursues higher performance, and Rest accounts for half of it, then gRPC is your only choice.

Of course, there are weaknesses, too. When debugging, it is not as comprehensive as HTTP, lacks various automated tools, and binary code is often confusing.

GraphQL

GraphQL is also relatively young, having only been around in 2015. It specifies the ability to retrieve only the “required” data.

In a traditional REST request, when you access a specific URL, you will get a relatively fixed result. No matter how many useless fields are in the returned data, the REST request will spit out the request to you.

GraphQL clients can decide what data to retrieve, and even how and in what format to retrieve the data - that is, to retrieve only the data it needs without generating too much useless data.

Github is the master of GraphQL. These interfaces are listed in detail at https://docs.github.com/en/graphql.

The following is a typical query syntax with variables. As you can see, this gives the request side, such as Js, similar programming capabilities.

 query ( $number_of_repos : Int ! ) {
 viewer {
 name
 repositories ( last : $number_of_repos ) {
 nodes {
 name
 }
 }
 }
 }
 variables {
 "number_of_repos" : 3
 }

Of course, its weaknesses are also obvious. Compared with directly requesting a certain address, these query statements make the request construction more complicated and the learning curve is relatively steep.

GraphQL is a good way to query complex resources, especially those with many fields and deep levels.

End

The above is a brief introduction to these three main methods. At present, REST is undoubtedly the most used because of its simplicity; gRPC has a rapid development momentum, especially in the field of microservices, and has been widely used; GraphQL is very complex, but of course it is a good tool for complex business data.

If your business is purely functional and the traffic is average, then there is no doubt that you can use REST to quickly implement it and get the money done; if your business has high performance requirements and the interaction method has a streaming form, then you can choose gRPC, which usually happens in the early stages of the project. Otherwise, you should still follow the company's infrastructure; GraphQL is relatively advanced, it is painful to introduce it, and the cycle is also long. Whether to use it to organize data depends on your determination.

But in any case, it is better to never use a cannon to shoot a mosquito than to use an embroidery needle to prick an elephant. It may not hit the mosquito, but yourself.

About the author: Xiaojieweidao (xjjdog), a public account that does not allow programmers to take detours. Focusing on infrastructure and Linux. Ten years of architecture, tens of billions of daily traffic, discussing the high-concurrency world with you, giving you a different taste.