Google Remote Procedure Call, more commonly known as gRPC, is a remote procedure call (RPC) framework that brings performance benefits and modern features to client-server applications. Like RPC, it allows you to directly call methods on other machines. It is fast, efficient, and secure, and allows you to generate code quickly.
Companies like Netflix, Spotify, and Docker have already transitioned to it, but does it make sense for others to go down the same path?
If you’re considering using it to build services, it’s one of several potential options. In this article, you’ll learn whether it makes sense for you.
Origins of gRPC
Prior to 2000, Remote Procedure Call (RPC) was the go-to method for service requests. RPC calls are efficient, but complex. They are tightly coupled to specific implementations and can be insecure, as they can expose too many internal details to the outside world.
Representational State Transfer (REST) was designed to solve these problems. It provides a common set of methods for client-server communication. GET and POST will be familiar to most web developers.
REST is easy to work with, but inefficient. There are limitations to its request-response model, and its data needs to be serialized for transmission, adding a performance overhead.
Enter Google
To improve this situation, Google developed gRPC. It launched in 2016, and is free and open source.
The “g” in its name may seem to stand for Google, but its meaning actually changes with every version. The RPC stands for Remote Procedure Call, the inter-system communication technology that it aims to replace and improve on.
Why use gRPC?
Performance benefits are a major advantage over other systems and a key reason to use gRPC.
In addition to being fast, gRPC pushes you into making good choices regarding security and code consistency. Its code generation tools make it quick to get started with, too.
Let’s talk about a few scenarios where gRPC shines before going into more detail about its technical and structural advantages.
For performance
gRPC’s combination of lightweight messages and high performance are useful in several scenarios.
When network resources are at a premium, gRPC’s lightweight messages are a better option than larger JSON messages. gRPC can be beneficial for smart devices or IOT communication, as well as any form of high-frequency communication.
Its low latency is beneficial for microservices, letting them communicate efficiently. It also works well for connecting mobile devices and browsers to backend services.
gRPC is also useful for interprocess communication (IPC), which has efficiency gains over TCP when sending messages between services on the same machine.
For development speed
gRPC’s auto-generation tools are useful for quickly generating client libraries. You can define your architecture using proto files, create code stubs automatically, and then flesh out the details. That gives you a head start in organization, which is useful when building a system with a complex architecture.
For microservice-based architectures, it lets you build systems at scale more easily. Keeping everything synchronized and compatible is less of a headache, and you’re less likely to make mistakes when dealing with multiple languages.
For additional capabilities
Bidirectional streams are ideal for communication, where you want to send messages without waiting for the other side to request them. In addition to being useful for internal communications between systems, it also has applications in messaging platforms and gaming.
Benefits of gRPC
There are many benefits to using gRPC, from both a technical and organizational standpoint.
Speed and efficiency
gRPC uses the Protocol Buffers (Protobuf) format. It allows for messages to be exchanged up to six times faster than JSON in some scenarios, with a size reduction of over thirty percent in others. Its messages are compressed and serialized.
It also requires a schema to make sure the underlying structure of the data is preserved wherever it is sent.
Bidirectional streaming
In addition to the standard client-server streams in either direction, gRPC includes bidirectional streaming. This allows you to create streams in both directions that can be fully or partially read without having to wait for the other direction to finish.
Messages in each stream are ordered, but the data flow in either direction can be started or stopped independent of the other direction’s status.
That could be used for communication-based applications, such as chat apps, or other interactive services, such as gaming, where each side wants to send communications to the other, and the overhead involved should be minimized.
As explained in Google’s documentation, you can create unidirectional or bidirectional streams like this:
Http/2
gRPC is designed for Http/2, which delivers several benefits. In addition to being more compact due to binary framing and compression, it lets you send multiple streams over a single connection. That eliminates head of line blocking at the application layer, meaning network packets are less likely to be held up by others in the queue.
It also features prioritization, so developers can get the most time-critical data sent first. Its server push features let servers guess what clients might want and send it without receiving a request.
Language agnostic
gRPC lets you build APIs based on contracts. These are described in a language agnostic binary format.
That’s another useful benefit, especially if you’re building a microservices-based system. It’s easier to get gRPC working with microservices written in different technologies when you have a common format to define the architecture.
Code generation
As well as being language agnostic, gRPC has excellent tooling and that allows for easy code generation. If you define an API specification using the .proto file format, you can use the protoc tool to generate code for you.
It supports many popular languages, including C++, Python, Ruby, JavaScript, and PHP.
For example, you can generate JavaScript output as follows:
Protoc doesn’t build fully functional APIs, but it generates code that includes serialization logic, as well as handling encoding. You need to handle data access and any further logic yourself.
However, there are language-specific projects that produce more detailed output, such as gRPC Elixir for Python. There are also tools that can take a simple model as input and generate a proto file and code for you, such as the GprcGenerator .NET project.
These code generation tools can save significant developer time.
Security
gRPC supports Transport Layer Security (TLS), and this is mandatory for connection to Google services. Token-based authentication is also supported.
Google’s authentication API allows you to create credential objects that can be attached to calls and channels to ensure security.
Formal specification
As gRPC is a formal specification, Google can explicitly declare what constitutes best practice. Subjective or not, it’s their spec, and they can make the decision for everybody.
With other specifications, such as HTTP, developers argue about the right way to do things. While this isn’t necessarily wrong, it does leave an inconsistency throughout people’s codebases. Having a set format eliminates that and ensures everyone either does it Google’s way, or accepts that they’re going against the grain.
Deadlines
gRPC lets you set deadlines for calls. That way, clients aren’t left hanging if the server doesn’t respond. For resource critical scenarios, or situations where fast response is needed, setting deadlines can give you granular control over the timing of your application’s communications.
Downsides of gRPC
Unsurprisingly, there are some caveats to be aware of if considering gRPC.
Browser support
Browser support hasn’t quite caught up to Http/2 yet. You can’t enforce its use or access raw Http/2 frames. If you want to take full advantage of it in browser-based apps, you’ll need to use an intermediary technology such as gRPC-Web.
As another alternative, you can create JSON APIs by using HTTP metadata and serve the JSON and gRPC together. This allows you to support browsers easily, though you won’t get the advantages of gRPC where it isn’t fully supported.
Immaturity
As a relatively new format, developers are less familiar with gRPC than with REST. However, gRPCs documentation is excellent and there is plenty of help for users getting started with it.
Non-human-readable messages
Another downside is that the Protobuf encrypted messages aren’t human-readable. If you’re debugging using Charles, Fiddler, or similar tools, you won’t find much to help you with gRPC.
However, there are tools to help with that, such as grpc-dump, from Bradley Kemp’s grpc-tools.
How can you get started?
If you want to get started with gRPC, there are plenty of ways to do it. Let’s take a look at the original documentation and add a very simple service to the existing code.
Google’s documentation is clear and thorough, and includes quickstart guides for 11 languages, including C++, Java, Python, and Kotlin.
For example, in Python, there’s a guide that shows you how to set up your virtual environment with the required libraries, download code from Git, and run it to create a barebones server with very little effort.
You can then launch a sample client in a separate window and watch it return a greeting message.
To add a simple service to return the server’s local time, modify the helloworld.proto file by adding this line to the greeter function:
At the end of the file, add the following functions:
Build the application code as in the existing example by running the following code from the examples/python/helloworld directory:
Update greeter_server.py with another definition after the SayHello def (and SayHelloAgain if you’ve added it). You’ll also need to import the time module at the top of the class:
In greeter_client.py, add the following to the run function below the existing calls:
If you launch the server and client, you’ll see a local time object returned, along with the existing calls.
It’s easy to see how you can build on this to create a full suite of services.
Final thoughts
gRPC offers a number of advantages over its predecessors, such as increased efficiency and bidirectional streams. It also offers security and consistency and helps you get started quickly. Limited takeup of Http/2 means you can’t rely on it being available, as only 46.3% of websites use it at present, and that number doesn’t seem to be increasing. For use cases where you have full control of the architecture, though, gRPC is a great choice. It’s also ideal for mobile applications that don’t require a browser.
If you're looking for a robust, maintenance-free solution to help you monitor your applications quickly, then check out Airplane. Airplane is the developer platform for building custom internal tools. With Airplane, you can transform SQL queries, Python scripts, API calls, and more into powerful workflows and UIs.
Airplane's engineering workflows solution also streamlines your most critical engineering-centric use cases. Build deployment pipelines, monitoring dashboards, database admin panels, and more.
To try it out and build your first engineering workflow using code, sign up for a free account or book a demo.
