“This is the 21st day of my participation in the First Challenge 2022. For details: First Challenge 2022”

We will first introduce gRPC and Protobuf to give you a basic idea of what gRPC is and what Protobuf is, and then further use and detail of both will follow.

1 gRPC

1.1 What is RPC

RPC generation refers to Remote Procedure calls, which include transport protocols, coding (object sequence) protocols, and so on, allowing programs running on one computer to Call subroutines on another without the developer having to program for this interaction. This is why we are often called RPC calls, which are just as convenient as local function calls.

1.2 What is gRPC

GRPC is a high-performance, open source, and generic RPC framework for mobile and HTTP/2 based design. The C version supports C, C++, Node.js, Python, Ruby, Objective-C, PHP, and C#.

Designed based on the HTTP/2 standard, gRPC brings features such as bidirectional streaming, flow control, header compression, and multiplexing requests over a single TCP connection. These features allow it to perform better on mobile devices and, in some cases, save space.

GRPC’s Interface Description Language (IDL) uses Protobuf, which is open-source by Google.

1.1 gRPC call model

Let’s take a look at a simple call model for gRPC to form a basic call flow in mind, as shown in the official figure below:

1. The client (gRPC Stub) invokes a method in the program to initiate an RPC call.

2. Object serialization compression (IDL) using Protobuf for request information.

3. After receiving the request, the Server (gRPC Server) decodes the request body, processes the business logic and returns it.

4. Object serialization compression (IDL) for response results using Protobuf.

5. The client receives the response from the server and decodes the request body. The callback to the called A method wakes up the client call waiting for A response (blocking) and returns the response result.

1 Protobuf

1.1 What is Protobuf

Protocol Buffers (Protobuf) is an extensible data description language that serializes structured data, independent of language and platform. It is often used for communication protocols, data storage, etc. Compared with JSON and XML, Protocol Buffers (Protobuf) is smaller, faster and more popular among developers.

1.2 Basic Syntax

syntax = "proto3";

package helloworld;

service Greeter {
    rpc SayHello (HelloRequest) returns (HelloReply) {}
}

message HelloRequest {
    string name = 1;
}

message HelloReply {
    string message = 1;
}
Copy the code

1. The first line (non-empty, non-commented line) declares the use of proto3 syntax. If not, the proto2 syntax is used by default. It is recommended that both v2 and V1 versions be explicitly declared. In terms of version, v1 version is currently recommended as the mainstream.

2. Define an RPC Service named Greeter that contains the RPC method SayHello with an incoming parameter of the HelloRequest message body and an outgoing parameter of the HelloReply message body.

3. Define the HelloRequest and HelloReply message bodies. Each body field contains three properties: type, field name, and field number. The definition of the message body is not repeatable except for the type.

After compiling the. Proto file, we usually compile and generate the proto file of the corresponding language. At this time, the Protobuf compiler will generate the Service Interface Code and Stubs of the corresponding language according to the selected language and the situation of the plug-in called.

1.1 Basic data types

After generating proto files for the corresponding language, it is important to note that protobuf does not generate exactly the same data type as the original, so you need to have a basic understanding. Here are some common type mappings I have listed:

.proto Type	C++ Type	Java Type	Go Type	PHP Type
double	double	double	float64	float
float	float	float	float32	float
int32	int32	int	int32	integer
int64	int64	long	int64	integer/string
uint32	uint32	int	uint32	integer
uint64	uint64	long	uint64	integer/string
sint32	int32	int	int32	integer
sint64	int64	long	int64	integer/string
fixed32	uint32	int	uint32	integer
fixed64	uint64	long	uint64	integer/string
sfixed32	int32	int	int32	integer
sfixed64	int64	long	int64	integer/string
bool	bool	boolean	bool	boolean
string	string	String	string	string
bytes	string	ByteString	[]byte	string

4 think gRPC

4.1 Comparison between gRPC and RESTful apis

features	gRPC	RESTful API
specification	Must be proto.	Optional OpenAPI
agreement	HTTP/2	Any version of HTTP
The payload	Protobuf (small, binary)	JSON (large, easy to read)
Browser support	No (grPC-web required)	is
streaming	Client, server, bidirectional	Client, server
Code generation	is	OpenAPI+ third-party tools

4.2 gRPC advantage

2 performance

The IDL used by gRPC is Protobuf. Protobuf can be quickly serialized on both the client and server, and the result after serialization is small, which can effectively save the data size occupied by transmission. In addition, many well-known, gRPC is based on HTTP/2 protocol design, there are very significant advantages.

In addition, people often ask why Protobuf, why gRPC does not use JSON, XML and other IDL, I think there are mainly the following reasons:

• It’s much simpler, much clearer in terms of definition.
• The data description file is 1/10 to 1/1 of the original size.
• Parsing is 20 to 100 times faster.
• It reduces ambiguity.
• Easier to use data access classes are generated.
• Fast serialization and deserialization.
• The developers themselves don’t have to pay much attention to the content in transit.

4.2.2 Code generation

In terms of code generation, we only need a PROTO file to define the convention of gRPC service and message body, and gRPC and its ecosystem provide a large number of tools to generate service base class, message body, client and other codes from the PROTO file. That is, the client and server share a proto file, to ensure the consistency of IDL and reduce duplication of work.

2 streaming

GRPC provides a lot of support for convection over HTTP/2:

1. Unary RPC: Unary RPC.
2. Server-side Streaming RPC: Streaming RPC on the Server.
3. Client-side Streaming RPC: Indicates the Client streaming RPC.
4. Bidirectional Streaming RPC: Indicates two-way streaming RPC.

4.2.4 Timeout and cancellation

GRPC allows the client to set the deadline. If the deadline is exceeded, the RPC request will be cancelled, and the server will receive the cancellation event. Therefore, both the client and the server can perform the related linkage processing of the cancellation event after the deadline.

In addition, according to the characteristics of the Go language context, the deadline can be passed down layer by layer, that is, we can spread the context deadline and cancel events through layer by layer gRPC call, which helps us deal with some upstream and downstream chain problems and other scenarios. However, it can also bring dangers. If not handled properly, the context of the first layer can be cancelled and the last call can be cancelled, which can be problematic in some scenarios (depending on the actual business scenario).

4.1 gRPC shortcomings

4.4.1 readability

By default, gRPC uses Protobuf as its IDL. Protobuf serialized data is essentially in binary format and is not readable, so it is not readable and cannot be directly visually debugged like HTTP/1.1, unless other special operations are performed to adjust format support.

4.1.2 Browser Support

Currently, we can’t call our gRPC service directly from the browser, which means that it’s not that convenient just for debugging, let alone for other application scenarios.

Yes, grPC-Web provides a JavaScript library that allows browser clients to access gRPC services, but it also has limited gRPC support (streaming support is weak). Grpc-web consists of two parts: a JavaScript client that supports the browser, and a GRPC-Web proxy on the server. The call process is as follows: The GRPC-Web client invokes the proxy, and the proxy forwards the request to the gRPC service.

But there are always additional components to support, so browser support is limited.

4.1.1 External Component Support

GRPC is designed based on HTTP/2, and the HTTP/2 standard was officially published in RFC 7540 in May 2015. Although several years have passed and HTTP/1 is already in the works, However, the support for HTTP/ 2-based components such as gRPC is still not perfect, and a few do not support it at all. At the same time, even if external components are supported, there is less information about them in the community, requiring some effort from developers to identify and study them, which is a point that needs to be addressed.

5 subtotal

In this chapter, we have introduced what gRPC and Protobuf are, and briefly compared gRPC’s strengths and weaknesses to traditional RESTful apis, in the hope of giving you a sense of what they are. In the following chapters, GRPC and Protobuf will be further explained and used.