JSON has long been the standard for API communication and the term “RESTful API” is thrown around everywhere. gRPC is the next iteration of service to service communication, it is superior in almost every way, from built-in code generation to pure speed. gRPC does this by using Protocol Buffers which are a way of encoding structured data in an efficient yet extensible format. It is Google’s official RPC implementation for Protocol Buffers.


gRPC is so much faster for a straightforward reason, encoding and decoding JSON is time-consuming and isn’t very space efficient. Behind the scenes gRPC takes the payload you give it and turns it into a binary blob using Protocol Buffers and the client receiving the data can efficiently translate that blob back into a structure. Speed wide usage may vary, but I’ve seen different accounts of x10 to x25 performance gains using gRPC over JSON. Here and here are a couple examples of benchmarks backing up that statement.


You build a .proto files to stores your definition. For those familiar with swagger, it is very similar to a swagger.json file. It has keywords like required, optional, and repeated (array) which reference Protocol Buffers definitions and are extremely powerful. They allow you to shape your data structure at the schema level in a programming language agnostic approach. Each supported language will give you validation, and for these keywords, for example, you cannot encode an object instance which has the required fields not filled in. Having this kind of flexibility encoded into the semantics of the serialization format is incredibly powerful.

You can also embed proto definitions inside others allowing lots of reuse within your proto definition, creating an opportunity for truly flexible and safe data transfer between services. Companies like Google use gRPC to significant effect, and I recommend checking out their tutorials for some inspiration.

Code Generation

One of the considerable benefits of using gRPC is code generation. gRPC is more than just the service definition, it can also be used for server and client code generation directly from the proto files. This is awesome! It means that you can focus your energy on writing application logic instead of repetitive boilerplate code. You can also update your proto files and be guaranteed that the generated code exactly matches the service definition.

As of the time of writing gRPC is supported in these languages:

  • C++
  • C#
  • Dart
  • Go
  • Java
  • Node.js
  • Objective-C
  • PHP
  • Python
  • Ruby

You can expect this list to get more extensive overtime, but this already covers the majority of serverside languages!


Finally, we come to readability, this is often overlooked as a reason to use gRPC. It can save developers quite a bit of time if you can just look at your proto file and have a feel for how the application works, and what it does. A proto file will describe what functions the service exposes as well as what the inputs and outputs of the functions expect. Below is an example proto file, notice how clear it is what this service is meant to do.

// The greeting service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
  // Sends another greeting
  rpc SayHelloAgain (HelloRequest) returns (HelloReply) {}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;

// The response message containing the greetings
message HelloReply {
  string message = 1;

To do this with a typical RESTful API, you have to comb through files looking for models, validation, etc… just to find out what each endpoint expects. It is clear that the proto file is a far more clear way of learning an service, even compared to Swagger.


It is clear that gRPC is the future of service to service communications. It has a leg up over JSON concerning speed, service definition, code generation, and readability. Although gRPC is very good for server to server communication JSON will still have a place for the foreseeable future for services which are consumed by web browsers. Hopefully in the future gRPC can overtake JSON for the web APIs for the obvious performance gains.

Categories: Architectures

Leave a Reply

Your email address will not be published. Required fields are marked *