gRPC

Google developed and released the initial version of gRPC (v1.0) in August 2016. Within the first year of its release, gRPC was adopted by startups, enterprise companies, and open-source projects worldwide. All gRPC's implementations are licensed under Apache License 2.0. It supports programming languages such as Android Java, C#, C++, Dart, Go, Java, Kotlin/JVM, Node.js, Objective-C, PHP, Python, and Ruby. Click here to see all the officially supported gRPC programming language, platform, and OS versions. The gRPC latest release tag is v1.33.2. Today, gRPC is used by Netflix, Square, CockroachDB, Cisco, Juniper Networks, and CoreOS, among others. 

The way the gRPC system works depends on the type of RPC method specified for a service. Since gRPC allows you to define four types of service methods, it'll be best to consider them independently to understand their RPC life cycle.

This is the simplest RPC method where the client sends a single request and waits to get back a single response. Here, the gRPC works in the following pattern:

1. Once the client calls a stub method, the server receives a notification that the RPC has been invoked with the client's metadata (information associated with the call to the server and vice versa) and the method name. The client can also specify a deadline or timeout for an RPC before it's terminated.

2. The server can then either return its own initial metadata straight away or wait to receive a client's request message. Unary RPC processing is application-specific.

3. Once the server gets the client's request message, it creates and populates a response doing whatever work is necessary to fulfil the client’s request. If the work is successful, the response is sent back to the client with the status detail (including status code and optional status message) and optional trailing metadata.

4. If the response status is OK, the client receives the response, which completes the call on the client's side.

This RPC lifecycle is similar to a Unary RPC. However, instead of the server returning a single response as with the Unary RPC, it returns a stream of messages in response to a client's request. Once the server gets the client's request message, it sends all its messages along with its status details (status code and optional status message) and optional trailing metadata to the client. The client completes the call once it has received all the server's messages.

This is also similar to a Unary RPC. However, instead of the client sending a single message to the server, it sends a stream of messages. Once the server gets the client's request message, it responds with a single message together with its status details (status code and optional status message) and optional trailing metadata. The server typically responds after it has received all the client's messages.

In a bidirectional streaming RPC, the client initiates the call by invoking the RPC method, and then the server receives the client metadata, method name, and deadline (if applicable). The server can either choose to return its own initial metadata straight away or wait for the client to start streaming messages. The process of bidirectional streaming is application-specific. Here, a server can wait until it has received all of a client's messages before writing its own messages, or the server sends back a response (after getting a request message), then the client sends another request based on the response received, and so on. The latter stream processing is like the server and client playing "ping-pong."

gRPC uses protocol buffers (Protobuf) by default as both the Interface Description Language (IDL) and underlying message interchange format. The protocol buffers enable developers to encode structured data. Protocol buffers also let you describe the service interface (service endpoints) and serializing structured payload messages.

gRPC is designed to use HTTP/2 (a binary protocol) as a transport. This transfer-based protocol supports multiplexing and the traditional Request/Response model. The protocol also enables developers to stream content or information constantly through various options such as server streaming, client streaming, or bidirectional streaming.

gRPC supports multiple authentication mechanisms such as SSL/TLS, ALTS, and token-based authentication with Google. SSL/TLS helps encrypt all the data or messages exchanged between the client and the server. gRPC uses ALTS as a transport security mechanism to protect data in transit. gRPC offers token-based authentication (typically an OAuth2 token) for specific auth flows while accessing Google APIs through gRPC.

gRPC integrates with popular tools such as Traefik, Ambassador, Continuous Delivery Service, Cilium, and BloomRPC, among others.

• High-quality HTTP implementations in every language  

• Supports Protobuf messages  

• Built on HTTP/2 transfer protocol  

• Supports various streaming options such as server-, client-, and bidirectional streaming 

• Uses request-response model 

• Support for internal services 

• No support for external services 

• No URL endpoints  

• The Mysterious Gotcha of gRPC Stream PerformanceBenefits and Best Practices of Adopting GRPC - XenonStack

• Google's gRPC: A Lean and Mean Communication Protocol for Microservices

• Core Concepts, architecture and lifecycle

• Building High Performance APIs In Go Using gRPC And Protocol Buffers