I recently spent some time researching gRPC and this post is a summary of what I learned. I also wrote a prototype application to test gRPC and gRPC-Web with Python and JS. The JS client takes a string from user input and test if it’s a palindrome. The code can be found on GitHub and in a future post I will comment on it.

What is gRPC?

gRPC is a remote procedure call framework developed and open-sourced by Google. As they explain in the documentation, gRPC “enables client and server applications to communicate transparently, and makes it easier to build connected systems“. For us who work in web development, think of gRPC as an alternative to using REST to make your frontend talk to your backend.

I know, REST is so popular and widely used that we don’t even think about using anything else!

How does gRPC compares to REST?

Both are tools to build distributed systems so choosing one over the other will depend on the use case. While REST (which stands for Representational State Transfer), is an architectural pattern, gRPC is a framework.

You could say that REST is about the resources and gRPC is about actions in the APIs.

In REST, the client has all the data about the current session. If data needs to be changed, the client sends all the information required to the server, who makes the change but it’s completely stateless.

In gRPC, the API interface is defined by describing the service behaviour: it specifies the methods that can be called remotely with their parameters and return types. Out of the box, gRPC uses protocol buffers as a language for describing both the service interface and the structure of the payload messages. Protocol buffers (or protobufs) are also used to serialize the data that will be transmitted and are simpler, smaller and faster than XML. The messages are encoded to a binary format (as opposed to text format in XML).

So bottom line is that gRPC is highly concerned with the service definition. You can also read in the official docs a more in-depth explanation why gRPC is better/worse than REST.

Why one should use gRPC?

According to the documentation, the advantages of using gRPC are:

• Starts quickly and scale
• Works across languages and platforms
• Bi-directional streaming and integrated auth
• Simple service definition – when using with Protocol Buffers

How to get started with gRPC

The first step to use gRPC is to establish the service definition. This service definition is quite crucial and it will drive everything else. After that, protoc (the compiler) will generate classes to be used in the implementation by the target languages.

Roughly, you should follow this order to create an application that uses gRPC:

1. Define your service (using protobufs or some other alternative)
2. Use protoc (a gRPC tool for compiling protocol buffers) for your target language
3. Use/import the classes generated with protoc in your implementation (server and/or client side)

In a separate post I will comment about my prototype. In the meantime, the code can be found here.

The post Getting Started with gRPC-part I: the what was originally published at flaviabastos.ca