gRPC - shilpas131/OVN-Poc GitHub Wiki

Inter-process communications are usually implemented using message passing with a synchronous request-response style or asynchronous event-driven styles. In the synchronous communication style, the client process sends a request message to the server process over the network and waits for a response message. In asynchronous event-driven messaging, processes communicate with asynchronous message passing by using an intermediary known as an event broker. Depending on your business use case, you can select the communication pattern that you want to implement.Inter-process communications are usually implemented using message passing with a synchronous request-response style or asynchronous event-driven styles. In the synchronous communication style, the client process sends a request message to the server process over the network and waits for a response message. In asynchronous event-driven messaging, processes communicate with asynchronous message passing by using an intermediary known as an event broker. Depending on your business use case, you can select the communication pattern that you want to implement.

When it comes to building synchronous request-response style communication for modern cloud native applications and microservices, the most common and conventional approach is to build them as RESTful services, where you model your application or service as a collection of resources that can be accessed and have their state changed via network calls that take place over the HTTP protocol. However, for most use cases RESTful services are quite bulky, inefficient, and error-prone for building inter-process communication. It is often required to have a highly scalable, loosely coupled inter-process communication technology that is more efficient than RESTful services. This is where gRPC, a modern inter-process communication style for building distributed applications and microservices, comes into the picture (we’ll compare and contrast gRPC with RESTful communication later in this chapter). gRPC primarily uses a synchronous request-response style for communication but can operate in fully asynchronous or streaming mode once the initial communication is established

gRPC (the “g” stands for something different in every gRPC release) is an inter-process communication technology that allows you to connect, invoke, operate, and debug distributed heterogeneous applications as easily as making a local function call.

When you develop a gRPC application the first thing that you do is define a service interface. The service interface definition contains information on how your service can be consumed by consumers, what methods you allow the consumers to call remotely, what method parameters and message formats to use when invoking those methods, and so on. The language that we specify in the service definition is known as an interface definition language (IDL).

The underlying gRPC framework handles all the complexities that are normally associated with enforcing strict service contracts, data serialization, network communication, authentication, access control, observability, and so on.

Service Definition

gRPC uses protocol buffers as the IDL to define the service interface.

Since the service definition is an extension to the protocol buffer specification, a special gRPC plug-in is used to generate code from your proto file.

// ProductInfo.proto syntax = "proto3"; 1 package ecommerce; 2

service ProductInfo { 3 rpc addProduct(Product) returns (ProductID); 4 rpc getProduct(ProductID) returns (Product); 5 }

message Product { 6 string id = 1; 7 string name = 2; string description = 3; }

message ProductID { 8 string value = 1; }

1 The service definition begins with specifying the protocol buffer version (proto3) that we use.

2 Package names are used to prevent name clashes between protocol message types and also will be used to generate code.

3 Defining the service interface of a gRPC service.

4 Remote method to add a product that returns the product ID as the response.

5 Remote method to get a product based on the product ID.

6 Definition of the message format/type of Product.

7 Field (name-value pair) that holds the product ID with unique field numbers that are used to identify your fields in the message binary format.

8 User-defined type for product identification number.

A service is thus a collection of methods (e.g., addProduct and getProduct) that can be remotely invoked. Each method has input parameters and return types that we define as either part of the service or that can be imported into the protocol buffer definition.

The input and return parameters can be a user-defined type (e.g., Product and ProductID types) or a protocol buffer well-known type defined in the service definition. Those types are structured as messages, where each message is a small logical record of information containing a series of name-value pairs called fields. These fields are name-value pairs with unique field numbers (e.g., string id = 1) that are used to identify your fields in the message binary format.

This service definition is used to build the server and client side of your gRPC application. In the next section, we’ll go into the details of gRPC server implementation.