top of page

gRPC - 101

What is gRPC?

gRPC (Remote Procedure Call) is a lightweight communication protocol from Google. This post covers what it means, how it works, and how it is different from REST.

gRPC Main Concepts

gRPC owes its success to the employment of two techniques:

  • Using HTTP/2 instead of HTTP/1.1

  • Using Protocol buffers as an alternative to XML and JSON.

Most of the gRPC benefits stem from using these technologies.

Protocol Buffers vs JSON

Enlisting some of the benefits of using ProtoBuf over of JSON that gives gRPC an edge:

  1. Small Size. Reduce CPU consumption

2. ProtoBuf(binary) is more efficient and faster, good for mobile platform.

3. ProtoBuf contract is generated automatically on the fly.

4. ProtoBuf messages allows communicating other micro services in different languages, there’s no languages restrictions in each micro services.

The problem gRPC essentially solves

Let’s imagine 2 people having a discussion in the same room. Both people speak the same language and the communication medium is essentially the same shared space in which the 2 people are speaking. For now we will keep it simple and make the assumption that the communication is unidirectional (communication happens in one way at a time).

  • The Sender sends a message (request) to the Receiver and waits for a response

  • The Receiver receives the message (request) and returns a response as another message

Because the 2 people are in the same room speaking the same language, the communication is very simple. There is no need for anything special to enable successful communication. For clarity, the following attributes can be observed for this type of communication.

  • Same language

  • Same space (non-distributed)

  • Same medium

The following diagram further illustrates how the communication occurs for this scenario.

Now imagine that we have 2 people that are in separate rooms, in different countries, and speak different languages. The following attributes contrast the difference to the example used above:

  • Different language

  • Different space (distributed)

  • Different medium

For this example, for successful communication to occur, we will need a mechanism to enable distributed communication. The mechanism will need to define some form of protocol (agreed upon rules) and will also need to do some form of encoding and decoding of messages sent between the Sender and the Receiver. This can be seen as illustrated in the diagram below.

Now imagine that we simply replace the 2 people with 2 computing systems. A Client and a Server. The Client may be a NodeJS Console Application written in Javascript. The Server could be running a C# .NET application. We have 2 separate systems that are running in different data centers and connected via a network. In other words we have a distributed computing system. In order for the Client and the Server to communicate, a mechanism with a protocol will need to be used. Protocol Buffers (Protobuf) and gRPC are just such a mechanism. The diagram below illustrates how our basic communication model can be translated into gRPC clients and server. The clients and server can be completely distributed and running in different data centers in different locations throughout the world.


Same APIs designed differently with gRPC vs REST

REST is a design principle, and HTTP is the most important/famous REST. HTTP methods like GET/PUT/POST/DELETE are used to call servers to read, modify, create or delete the resources respectively.

GET /users/{userID}

Whereas, RPC exposes server methods via Client Stubs (explained later) to enable clients to interact with their system.




The gRPC supports four types of RPC:

  1. Unary RPC: the client sends a single request and receives a single response.

  2. Server streaming RPC: the client sends a single request; in return, the server sends a stream of messages.

  3. Client streaming RPC: the client sends a stream of messages, and the server responds with a single message.

  4. Bidirectional streaming RPC: in bidirectional streaming, both the client and server send a stream of messages.

Additionally, a gRPC RPC can be synchronous or asynchronous.

  • Synchronous: a client call waits for the server to respond.

  • Asynchronous: client makes non-blocking calls to the server, and the server returns the response asynchronously.

Advantages of gRPC

gRPC offers critical advantages over other technologies like REST.

  1. Performance – gRPC uses protocol buffers, a binary format for serializing data. A protocol buffer is much more efficient and performant than JSON or XML used by REST APIs.

  2. Type safety – gRPC uses a strongly typed IDL, which reduces the risks of the runtime error caused by casting to the wrong data type.

  3. Multi-language support – gRPC supports many programming languages, which makes it easier to use the adequate programming language for each microservice.

  4. Code generation – gRPC can generate the client code and the server code to serialize the messages, which reduces the amount of boilerplate the developer has to write and speeds up the development process.

  5. Streaming – gRPC offers bi-directional streaming between the client and server.

While gRPC is an excellent piece of technology, it is not without its downsides, and these should be considered before deciding to use gRPC for your API.

Downsides of gRPC

  1. Complexity

  2. Learning Curve

  3. Debugging

  4. Versioning

gRPC - suitable for following requirements.

  • Real-time communication services where you deal with streaming calls

  • When efficient communication is a goal

  • In multi-language environments

  • For internal APIs where you don’t have to force technology choices on clients

  • New builds as part of transforming the existing RPC API might not be worth it

Some Popular gRPC UseCases

  • Microservices – gRPC is designed for low latency and high throughput communication. gRPC is great for lightweight micro-services where efficiency is critical.

  • IoT and mobile devices – gRPC's lightweight and efficient communication makes it a good choice for communication between IoT devices and mobile devices and the backend systems.

  • Point-to-point real-time communication – gRPC has excellent support for bi-directional streaming. gRPC services can push messages in real-time without polling.

  • Polyglot environments/Cross-platform applications – gRPC's multi-language support and platform-agnostic design make it a good choice for building applications that run on different platforms and use other programming languages.

  • Network constrained environments – gRPC messages are serialized with Protobuf, a lightweight message format. A gRPC message is always smaller than an equivalent JSON message.


While gRPC does have some downsides and challenges, such as its complexity and learning curve, these are outweighed by its benefits in many use cases. gRPC's multi-language support, code generation, and strong type safety make it a good choice for building modern cross-platform applications requiring fast and efficient communication between different system parts.

Whether you're building microservices, IoT devices, or high-performance data processing systems, gRPC offers a powerful and flexible communication layer to help you achieve your goals. By taking advantage of gRPC's features and benefits, you can build faster, more efficient, and more scalable systems that adapt and evolve with your needs.


213 views0 comments


Copyright © 2020 TechTalksByAnvita

bottom of page