- gRPC Tutorials
- gRPC - Home
- gRPC - Introduction
- gRPC - Setup
- gRPC - Helloworld App with Java
- gRPC - Helloworld App with Python
- gRPC - Unary
- gRPC - Server Streaming RPC
- gRPC - Client Streaming RPC
- gRPC - Bidirectional RPC
- gRPC - Client Calls
- gRPC - Timeouts & Cancellation
- gRPC - Send/Receive Metadata
- gRPC Useful Resources
- gRPC - Quick Guide
- gRPC - Useful Resources
- gRPC - Discussion
- Selected Reading
- UPSC IAS Exams Notes
- Developer's Best Practices
- Questions and Answers
- Effective Resume Writing
- HR Interview Questions
- Computer Glossary
- Who is Who
gRPC - Introduction
Before we jump into gRPC, let us have a brief background about remote procedure calls which is what gRPC does.
What are Remote Procedure Calls?
Remote procedure calls are the function calls which look like general/local function calls but differ in the fact that the execution of remote functions calls typically take place on a different machine. However, for the developer writing the code, there is minimal difference between a function call and a remote call. The calls typically follow the client-server model, where the machine which executes the call acts as the server.
Why do we need remote procedure calls?
Remote procedure calls provide a way to execute codes on another machine. It becomes of utmost importance in big, bulky products where a single machine cannot host all the code which is required for the overall product to function.
In microservice architecture, the application is broken down into small services and these services communicate with each other via messaging queue and APIs. And all of this communication takes place over a network where different machines/nodes serve different functionality based on the service they host. So, creating remote procedure calls becomes a critical aspect when it comes to working in a distributed environment.
Why gRPC?
Google Remote Procedure Calls (gRPC) provides a framework to perform the remote procedure calls. But there are some other libraries and mechanisms to execute code on remote machine. So, what makes gRPC special? Let's find out.
Language independent − gRPC uses Google Protocol Buffer internally. So, multiple languages can be used such as Java, Python, Go, Dart, etc. A Java client can make a procedure call and a server that uses Python can respond, effectively, achieving language independence.
Efficient Data Compaction − In microservice environment, given that multiple communications take place over a network, it is critical that the data that we are sending is as succinct as possible. We need to avoid any superfluous data to ensure that the data is quickly transferred. Given that gRPC uses Google Protocol Buffer internally, it has this feature to its advantage.
Efficient serialization and deserialization − In microservice environment, given that multiple communications take place over a network, it is critical that we serialize and deserialize the data as quickly as possible. Given that gRPC uses Google Protocol Buffer internally, it ensures quick serializing and deserializing of data.
Simple to use − gRPC already has a library and plugins that auto-generate procedure code (as we will see in the upcoming chapters). For simple use-cases, it can be used as local function calls.
gRPC vs REST using JSON
Let’s take a look at how other ways to transfer data over a network stack up against Protobuf.
| Feature | gRPC | HTTP using JSON/XML |
|---|---|---|
| Language independent | Yes | Yes |
| HTTP version | HTTP/2 | HTTP 1.1 |
| Specifying Domain Schema | .proto files (Google Protocol Buffer) | None |
| Serialized data size | Least | High (higher for XML) |
| Human Readable | No, as it uses separate encoding schema | Yes, as it uses text based format |
| Serialization speed | Fastest | Slower (slowest for XML) |
| Data type support | Richer. Supports complex data types like Any, one of etc. | Supports basic data types |
| Support for evolving schema | Yes | No |