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:
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.
gRPC vs REST
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.
server.getUser(userID);
gRPC
REST
The gRPC supports four types of RPC:
Unary RPC: the client sends a single request and receives a single response.
Server streaming RPC: the client sends a single request; in return, the server sends a stream of messages.
Client streaming RPC: the client sends a stream of messages, and the server responds with a single message.
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.
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.
Type safety – gRPC uses a strongly typed IDL, which reduces the risks of the runtime error caused by casting to the wrong data type.
Multi-language support – gRPC supports many programming languages, which makes it easier to use the adequate programming language for each microservice.
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.
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
Complexity
Learning Curve
Debugging
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.
Conclusion
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.