gRPC and related definitions

Tram Ho

This document introduces key definitions of gRPC and an overview of the architecture of gRPC and the Life Cycle of RPC. What does this article assume you have read about gRPC?


Service Definition

Start with the code below.

gRPC allows defining 4 types of service methods:

Unary RPCs when the client sends a request to the server and receives a response like a normal method call.

Server streaming RPCs when the client sends a request to the server and receives a stream to read the sequence of the returned message.

Client streaming RPCs when the client records a sequence of messages sent to the server, the stream is used. The client will finish sending its message, then wait for the server to respond. gRPC guarantees ordering messages during an individual RPC call.

Bidirectional streaming RPCs when both send a sequence of messages using read-write streams. Two threads are independent or dynamic, so that the client and server can read and write in any order they want: for example, the server can wait to receive all client messages before writing a response or can read it. The message then writes the message or some other read and write combination. The order of messages in each thread is preserved.

API surface

Starting with the service definition in the .proto file, gRPC provides protocol buffers that generate code on the client and server side. GRPC users often call these APIs on the client side and deploy accordingly on the server side.

  • On the server side, deploy the methods described by the service and run a gRPC server to handle calls from the client. gRPC infrastructure decodes requests, implements service methods, and encodes responses.
  • On the client side, there is a local object called the stub that implements self-service methods. The client can then simply call those methods on the local object, wrapping parameters for the appropriate protocol buffer message type – gRPC considers it after sending the request (s) to the server and the server returns ( ) response to the protocol buffer.

Synchronous vs. asynchronous

RPC calls block synchronously until a response comes from the server. gRPC in programming languages ​​has both dynamic and asynchronous RPC.

RPC life cycle

Unary RPC

A simple RPC, when a client sends a request to the server and receives a response.

  • When the client invokes the method on the stub / client object, the server is notified that the RPC has been called with the client metadata for this call, the method name and the specified deadline (if specified).
  • The client can then resubmit its own original metadata (which must be sent before any responses are received), or wait for the client’s request notification – the first thing that happens is application specific.
  • When the server issues a client request message, it does whatever it takes to create and respond to it. The response is then returned (if successful) to the client along with status details (status codes and optional status messages) and optional trailing metadata.
  • If the status is OK, the client will receive a response, completing the call on the client side.

RPC streaming server

A server-streaming RPC is similar to the simple example in Unary RPC, except that the server sends back a response stream after receiving a request from the client. After sending all of its responses, server status details (status codes and optional status messages) and optional trailing metadata are sent back to completion towards the server.Client is completed once It has all server responses.

Client streaming RPC

A RPC client-streaming is similar to the simple example in Unary RPC, except that the client sends a request stream to the server instead of a request. The server sends a unique response, usually but not necessarily after receiving all client requests, along with optional status and trailing metadata.

Bidirectional streaming RPC

A bidirectional streaming RPC is a combination of Server streaming and Client streaming RPC. Because the server and the client can read and write in any order – the streams operate independently.

Deadlines / Timeouts

gRPC allows clients to specify the time they are willing to wait for RPC to complete before RPC is terminated with the DEADLINE_EXCEEDED error. The server side can query to see if a particular RPC has expired or how much time is left to complete the RPC.

The specified deadline or waiting timeout varies by language – for example, not all languages ​​have default deadlines, some language APIs work by deadlines (fixed times) and some Language API works by timeout (duration).

RPC termination

In gRPC, both the client and the server make independent and local decisions about the success of the call and their conclusions may not match. This means that, for example, you might have an RPC that ended successfully on the server side, but failed on the client side. (The response has arrived after the deadline.) It can also let the server decide to complete. before the client sends all its requests.

Canceling RPCs

The client or server can cancel RPC at any time. The cancellation terminates RPC immediately so no further work can be done. This is not a perfect way, changes made before canceling will not be rolled back.


Metadata is information about a specific RPC call (such as authentication) in the form of a list of key-value pairs, where keys are strings and values ​​are often strings (but can be data. binary).

Access to metadata depends on the language.


The gRPC channel provides connection to the gRPC server on the specified server and port and is used when creating the client stub (or just the client in some languages). The client can specify a channel argument to modify the default behavior of gRPC, such as enabling and disabling message compression. A channel has status, including connected and idle.

The way gRPC handles closing channels depends on the language. Some languages ​​also allow channel status queries.


[HANOI_Techtalk] At the Techtalk on January 14, 2020 with the topic “Migrating APIs from REST to gRPC and LOOP Case study” by Mr. Viet Nguyen – CTO | LOOP presents, promising to bring solutions to the problem of communication between services from the LOOP case itself.

Chính The main contents of this sharing session:

  • What is the gRPC (Remote Procedure Calls) system developed at Google gRPC?
  • What problems does the LOOP team encounter during product development? How do your services communicate with each other?
  • Challenges encountered and how to deploy them?

= = =

** Enter the code EARLYBIRD @ 1401 to reduce 100,000 VND for the first tickets!

Gian Period: 18:30 – 21:00 on January 14, 2020
📌 Location: UP Polytechnic Hanoi, 3rd floor of Building A1-7, 17 Ta Quang Buu, HBT.
Ngay Register now at:



Event team: | 028 6681 3236
Ms. Dab | | 038 5098 969

=== Weekly event in PRODUCT IN REAL LIFE ( ) weekly organized by TopDev – IT recruitment solution ===

Share the news now

Source : Techtalk