Beginner's guide to gRPC

6 min readSep 30, 2022

If you’re new to gRPC (Remote Procedure Call) , then this article is for you! 🎉 These past few days I have been exploring and diving deep into gRPC and I found a lot of interesting things. I will be sharing those things through my writing.

In this article, I will outline some of the basic concepts of gRPC. For clarity, this guide is structured into several sections.

So let’s get started!🍾 🎉

What is gRPC?

gRPC is a modern open source high performance Remote Procedure Call (RPC) framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication.

This framework relies on HTTP/2, protocol buffers, and other modern technology stacks to ensure maximum API security, performance, and scalability. Let’s go deep in to these concepts.

Basic gRPC Concepts

Protocol Buffers

Protocol Buffers is an open-source cross-platform data format used to serialize structured data. gRPC uses Protocol Buffers as Interface Definition Language to create service contracts, detailing all of its remote functions and message formats. Its current version is proto3, which has the latest features and is easier to use.

The proto files are used to define gRPC services and messages between clients and servers. As this is in the form of a contract, both the client and server need to have the same proto file. The proto file acts as the intermediary contract for client to call any available functions from the server.

The Protobuf compiler, protoc, generates client and server code that loads the .proto file into the memory at runtime and uses the in-memory schema to serialize/deserialize the binary message. After code generation, each message is exchanged between the client and remote service.

Since data is translated into a binary format and encoded messages are smaller, parsing with Protobuf uses utilizes less CPU resources. Therefore, even on computers with a slower CPU, such mobile devices, messages are exchanged more quickly.

HTTP/2

gRPC is developed on HTTP/2. HTTP/2 was published in 2015 as the most popular transport protocol on the internet to overcome the HTTP/1.1 limitations. HTTP/2 is one of the big reasons why gRPC can perform so well. Some advantages are .

Binary Framing Layer — Unlike HTTP/1.1, HTTP/2 request/response is divided into small messages and framed in binary format, making message transmission efficient. With binary framing, the HTTP/2 protocol has made request/response multiplexing possible without blocking network resources.
Streaming — Bidirectional full-duplex streaming in which the client can request and the server can respond simultaneously.
Flow Control — Flow control mechanism is used in HTTP/2, enabling detailed control of memory used to buffer in-flight messages.
Header Compression — Everything in HTTP/2, including headers, is encoded before sending, significantly improving overall performance. Using the HPACK compression method, HTTP/2 only shares the value different from the previous HTTP header packets.
Processing — With HTTP/2, gRPC supports both synchronous and asynchronous processing, which can be used to perform different types of interaction and streaming RPCs.

Streaming

Another fundamental concept in gRPC is streaming, which allows multiple processes to happen in a single request. It is made feasible by HTTP/2’s multiplexing capabilities, which allows for the sending and receiving of numerous requests simultaneously over a single TCP connection. In gRPC, we can have streaming with three functional call types:

Server-streaming RPCs — The client sends a single request to the server and gets back several messages that it reads sequentially.
Client-streaming RPCs — The client sends a sequence of messages to the server. The client waits for the server to process the messages and returns a single response to the client.
Bidirectional-streaming RPCs — The client and server can send multiple messages back and forth. The messages are received in the same order that they were sent. However, the server or client can respond to the received messages in the order that they choose.

gRPC Channels

A gRPC channel specifies the port for connecting to the gRPC server on Integration Server as well as the authentication credentials used by the gRPC server for TLS support and are used in creating a client stub.. The port in the gRPC channel is an HTTP/2 port that is managed by the gRPC server embedded in Integration Server. Because each gRPC descriptor must be associate with an HTTP/2 port, a gRPC channel must exist and be enabled before you creating the gRPC provider descriptor.

Metadata

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

Header can be assigned from the client side, while servers can assign Header and Trailers so long as they're both in the form of metadata.

So as a summary of all above concepts, following makes gRPC special.

Language independent
Efficient Data Compaction
Efficient serialization and deserialization
Simple to use
More Secure

gRPC Architecture

The client and server sides of gRPC are shown in the following diagram.

Every client service in gRPC contains a stub (auto-generated files), which is like an interface that contains the current remote procedures.
The local procedure call to the stub with parameters for the server is made by the gRPC client.
The client stub then sends the request to the local client-time library on the local machine after serializing the parameters using the protobuf marshaling process.
Then the OS makes a call to the remote server machine via HTTP/2 protocol.
The server’s OS receives the packets and calls the server stub procedure.
Server stub procedure decodes the received parameters and executes the respective procedure invocation using Protobuf.
The server stub then sends back the encoded response to the client transport layer.
The client stub receives back the result message and unpacks the returned parameters,
Then the execution returns to the caller.

Why gRPC over REST?

Protobuf instead of JSON/XML

REST uses JSON for sending and receiving messages while gRPC uses protocol buffers, which are a better way of encoding data. As JSON is a text-based format, it will be much heavier than compressed data in protobuf format. So protobuf can save you bandwidth and improve network performance.

2. Built on HTTP 2

Basic gRPC ConceptsREST is built on HTTP 1.1 which is basically a request-response model. while gRPC uses HTTP2 which supports client-response communication and bidirectional streaming. In HTTP 1.1, when multiple requests come from multiple clients, they are served one by one. This can slow down the system. HTTP 2 allows multiplexing, so multiple requests and responses can be served at the same time.

3. First-class support for code generation

REST needs third-party tools to generate the code for API calls.
gRPC comes with an in-built protoc compiler which provides the code generation features by default.

4. Multiple languages and platforms support
gRPC supports a broad spectrum of languages such as C/C++, C#, Dart, Go, Java, Node.js, Objective-C, PHP, Python and Ruby. This helps developers to choose the right language depending on their use cases.

Weaknesses of gRPC

Limited Browser Support

It is not possible to directly call a gRPC service from a web browser because gRPC mainly relies on HTTP/2. No current browser offers the web request control necessary to support a gRPC client. Therefore, conversions between HTTP/1.1 and HTTP/2 must be handled by a proxy layer and gRPC-web.

2. Non-human Readable Format

gRPC messages are compressed by protobuf into a non-human readable format. In order to debug, write manual requests, and analyze Protobuf payloads across the wire, developers require extra tools like the gRPC command-line tool.

3. Steeper Learning Curve

Compared to REST and GraphQL, which primarily use JSON, it will take some time to get acquainted with protocol buffers and find tools for dealing with HTTP/2 friction

So far, we’ve covered basics of gRPC and it’s features. I truly hope this article helped you to understand more about gRPC. But there’s still a lot more to learn, so don’t stop here! Stay tuned for more with gRPC 😎👊.

References