# All about gRPC
If you build systems that require high-speed communication, you will probably want to take a look at gRPC. gRPC, short for Google Remote Procedure Call, is an open-source framework developed by Google for fast and effective communication between software systems. Currently, with support for [eleven programming languages](https://grpc.io/docs/languages/), gRPC is widely used for inter-service communication in distributed systems or for connecting mobile or browser clients to backend services.
This article provides an overview of gRPC, including its functionalities, benefits, drawbacks, use cases, practical applications, and more. The article also compares gRPC with REST, which is another one of the most common communication methods used in the context of designing APIs and building distributed systems.
## Why Is gRPC So Popular?
gRPC was publicly released in 2016 and is known for its efficiency and high performance. The framework follows the remote procedure call (RPC) principle, allowing services to communicate by invoking methods on remote services as if they were local.
Four key methods govern the transmission and reception of RPC requests and responses, and these methods collectively form the RPC lifecycle:
- **Unary RPC:** A simple RPC where the client sends a single request to the server and then waits for the response, just like a normal function call.
- **Server streaming RPC:** A server-side streaming RPC method in which the client sends a request to the server and receives a stream of messages in response. The client reads from the returning stream until no more messages are found.
- **Client streaming RPC:** A method similar to server streaming, but in this case, the client sends a stream of messages to the server. When the client has completed writing all of the messages, it waits for the server to read them all and respond.
- **Bidirectional streaming RPC:** A model where both the client and server use a read-write stream to convey a series of messages. Because the two streams function independently, clients and servers can read and write in whatever sequence they want.
gRPC is widely used in event-driven architecture, a design pattern commonly employed in distributed systems for communication between services. In this design pattern, when an event occurs in one service, it triggers specific actions in one or more other services. In high-traffic systems that handle thousands to tens of thousands of requests per second, multiple events are triggered rapidly, requiring fast inter-service communication to handle the request volume. Sometimes, these services need to communicate synchronously, especially when immediate responses are necessary. In such cases, gRPC can be utilized in an event-driven architecture to trigger actions that are not event-related, facilitating quick and efficient communication between services.
gRPC achieves high speed and performance through the use of a [binary protocol](https://handwiki.org/wiki/Binary_protocol) and HTTP/2. A binary protocol is a communication protocol that leverages bytes as its standard for representing data. gRPC also uses [protocol buffers](https://protobuf.dev/), a small, fast, and simple model, as its format for serializing structured data before it's transferred using the binary protocol.
## Protocol Buffers in gRPC
Protocol buffers, also developed by Google and widely known as Protobuf, utilize the most commonly used interface definition language (IDL) in gRPC for data serialization. Protobuf is language-independent and provides a way to structure data efficiently, making it easier to exchange information between systems developed with different programming languages through the use of a neutral schema to define the structure of the data.
This schema is defined in a `.proto` file using a simple language called the protocol buffer language, which allows developers to specify the fields and types of data they want to encode. This schema serves as a contract between the gRPC client and server on the structure of data to be sent and received. Once the schema is defined, the protocol buffer compiler generates code in the requested language that may then be used to serialize and deserialize data according to the defined schema. The generated code includes APIs for interacting with data, making it easy to encode and decode messages.
## gRPC vs. REST
Understanding the potential of gRPC is easier when you compare it to another popular request-response model like REST. By examining the similarities and differences between gRPC and REST, you can assess the distinct advantages and considerations that come with each approach.
REST, short for representational state transfer, serves as an architectural standard for communication between two services. Operating on the foundation of HTTP/1.1, REST employs a human-readable format like JSON to facilitate data transfer between services. In the REST paradigm, the originating service acts as the client, while the receiving service is referred to as the server. In REST, a [URI](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier) is used to select the desired resource along with the equivalent HTTP verb (such as GET, PUT, or POST) specifying the operation to be performed.
Although there are certain similarities between gRPC and REST, there are also very important differences.
### Protocol (HTTP/1.1 vs. HTTP/2)
REST predominantly uses HTTP/1.1 as its default underlying protocol while also offering support for HTTP/2. However, REST follows a request-response-based model. So, when multiple requests are sent to a service at once, each request is handled individually, which generally slows down the response time of the system. To handle multiple requests simultaneously, further effort is required to implement paradigms such as asynchronous processing and multithreading. These issues are nonexistent in gRPC.
gRPC uses a client-response-based model and is built on HTTP/2. It supports streaming and bidirectional communication, meaning it can handle multiple requests simultaneously without requiring additional configurations or setup.
### Speed
Setting up a REST service takes significantly less time than setting up a gRPC-based one. However, in terms of data transfer, gRPC can often produce faster results, with some sources reporting it to be up to [seven times faster than REST](https://blog.dreamfactory.com/grpc-vs-rest-how-does-grpc-compare-with-traditional-rest-apis/). This is mostly due to its use of advanced compression, which leads to a much smaller data size, and its binary format for encoding, which leads to smaller packets of data required to be transmitted.
### Data Format
REST relies on formats such as JSON and XML to transfer data. The widespread popularity of these formats brings several advantages, including a broader range of available resources and community support. Additionally, these formats offer readability and flexibility, allowing for the transmission of dynamic data without strict adherence to a specific structure.
gRPC, on the other hand, supports protocol buffers (Protobuf) for serialization, leading to smaller data transfer packets due to its high compression. Deserialization into various programming languages is also faster and easier with Protobuf because it encodes data in binary format, which requires less bandwidth during data transfer.
### Browser Support
Limited browser support is one of the main concerns with using gRPC. gRPC utilizes HTTP/2, which is only supported by a few browsers, excluding older versions. However, efforts have been made to address this issue by introducing [gRPC-web](https://github.com/grpc/grpc-web) and using a proxy layer to convert between HTTP/2 and HTTP/1.1. In contrast, REST relies on HTTP/1.1, which is supported by all browsers. If you need more information, [caniuse.com](https://caniuse.com/) has a comprehensive list of browsers and browser versions with support for HTTP/2.
### Security
In REST, the HTTP/1.1 protocol is used, and the data format is typically JSON or XML. This makes it relatively easy to decrypt and access the data. On the other hand, gRPC employs a binary format with protocol buffers and HTTP/2, which enhances security and makes it more challenging to decrypt the data. The default features of HTTP/2 contribute to this increased security. For example, header compression reduces the overhead of transmitting headers with each request. This compression technique makes it more difficult for attackers to exploit header information for various types of attacks, such as request smuggling or injection.
Additionally, HTTP/2 offers built-in support for TLS encryption. This ensures the confidentiality and integrity of the transmitted data by safeguarding against eavesdropping and tampering attempts by attackers.
## gRPC Use Cases
There are many different use cases where gRPC is preferred over REST. In terms of streaming capabilities and speed, gRPC is often the more desirable option because it can handle much larger amounts of data in a shorter amount of time. Additionally, the handling of multiple requests in gRPC is another factor that makes it a popular choice for developers.
### gRPC Backend for a Frontend Application
REST APIs have certain limitations that can impact development, particularly in scenarios requiring streaming capabilities. This is mostly evident in cases that require communication between a web client (frontend and mobile) and the backend server. The following are examples of such cases:
- **File upload:** With gRPC, file uploads can leverage the client streaming RPC model, where the file is sent from the web client to the server via a stream. This model allows for the transfer of large files without the need to buffer the entire file in memory before sending it to the server. Furthermore, the server can start processing the file as soon as it receives the first chunk, allowing for more efficient file uploads. Using gRPC for a file upload provides a secure way to transfer files over the network, as it includes support for Transport Layer Security (TLS) encryption. Additionally, gRPC supports bidirectional streaming, which enables the server to send status updates to the client during the file upload process. This feature can help improve the user experience by providing real-time feedback on upload progress.
- **Real-time applications:** gRPC is well-suited for real-time communication applications like chat, messaging, maps, and financial data charts (such as stock and foreign exchange markets). This is due to its support for bidirectional streaming, which allows continuous data exchange between the client and server through read-write streams. This feature enhances communication efficiency and enables seamless real-time interactions between both the client and the server.
### Event-Driven Applications
Many large companies, spanning diverse domains like location tracking, streaming, and IoT, apply gRPC in event-driven architectures, including some of the world's leading tech giants:
* **Netflix:** For some time now, Netflix has been leveraging gRPC to facilitate data exchange among multiple microservices within its stream processing pipeline. This empowers Netflix to deliver uninterrupted streaming experiences to its users, regardless of their geographical location.
* **Cockroach Labs:** [CockroachDB](https://en.wikipedia.org/wiki/CockroachDB) is a popular, open-source, distributed database system developed by Cockroach Labs in 2014 to offer scalability, consistency, and fault tolerance. CockroachDB [relies extensively on gRPC](https://www.cockroachlabs.com/docs/stable/architecture/distribution-layer.html#:~:text=Because%20the%20distribution%20layer%20is,protocol%2Dbuffer%2Dbased%20API.) for communication between its distributed components. This enables efficient communication across the database cluster, achieving high performance and low latency through the use of gRPC's binary serialization and request multiplexing supported in HTTP/2. gRPC serves as the underlying framework for seamless coordination among the distributed nodes, enhancing CockroachDB's overall performance.
Many other products and organizations, such as Square, Docker, and Cisco, also use gRPC for communication and data transfer in their architecture.
## Example of gRPC in Event-Driven Architecture
As mentioned, gRPC can enable direct communication between services in an event-based architecture. For example, in a booking system, the booking service can utilize gRPC to send a request to the payment service and receive an immediate response regarding a client's payment status. This allows the booking service to make prompt decisions on whether to confirm or reject the booking.
To ensure smooth communication between services, both the booking service (implemented in Golang) and the payment service (implemented in C#) need to establish a shared schema using Protobuf. This schema defines the request and response formats and is stored in a `.proto` file containing the payload with all the required properties and their data types for both the request and response.
A typical `.proto` file for this instance will look like the following:
```protobuf
syntax = "proto3";
// The payment service definition
service PaymentService{
// Initiate payment
rpc InitiatePayment(PaymentRequest) returns (PaymentResponse);
}
// The request message containing the client info and payment details
message PaymentRequest {
string name = 1;
string cardPan= 2;
int32 cvv = 3;
string expiry = 4;
}
// The response message containing the payment result
message PaymentResponse {
bool success = 1;
string message = 2;
}
```
Following the specification of the schema in the file, you can then use the protocol buffer compiler (`protoc`) to generate the data access classes and structs in the C# and Golang projects, respectively. The generated classes provide accessors for the fields, as well as methods to serialize or deserialize the data between raw bytes and language-specific structure for data transfer.
With the accessors in place, making requests becomes straightforward. Here's an example of how to do so:
```ts
try {
using var channel = GrpcChannel.ForAddress(url);
var client = new PaymentService.PaymentServiceClient(channel);
PaymentResponse response = await client.InitiatePaymentAsync(new PaymentRequest
{
name = true,
cardPan = "xxxx xxxx xxxx 5678”,
cvv = 234,
expiry = "02/25"
});
// Use response
}
catch (Exception ex) {
// Handle exception
}
```
## Conclusion
In this article, you learned about gRPC, how it works, its benefits and drawbacks, and how it compares to REST, as well as multiple use cases where gRPC can be applied both in event-driven architecture or in direct server-to-server or server-to-client communication. You also saw an example of how gRPC would work in an application that uses an event-driven architecture.
Overall, gRPC shines in use cases that require high performance, streaming capabilities, language interoperability, and advanced error handling. While REST remains a popular choice for many applications, gRPC offers a compelling alternative for specific scenarios where its unique features and capabilities are advantageous. For developers working on applications that demand fast and efficient communication, exploring gRPC is highly recommended. With this article, you have all the information you need to make informed decisions on when gRPC is best for you and why it will thrive in that case.
