Welcome back, every one! In this lecture, we will discover some use cases of gRPC and how does it compare to REST.

Here's the link to the full gRPC course playlist on Youtube
Github repository: pcbook-go and pcbook-java
Gitlab repository: pcbook-go and pcbook-java

Types of gRPC

There are 4 types of gRPC:

The simplest one is Unary, where the client sends 1 single request message and the server replies with 1 single response. This looks somewhat similar to the normal HTTP REST API.

Then we have client-streaming. In this scenario, the client will send a stream of multiple messages, and it expects the server to send back only 1 single response.

Similarly, we have server-streaming, where the client sends only 1 request message, and the server replies with a stream of multiple respnoses.

And finally, the bidirectional (or bidi) streaming. This one is the most complex because client and server will keep sending and receiving multiple messages in parallel and with arbitrary order. It’s very flexible and no blocking, which means no sides need to wait for the response before sending the next messages.

That’s a very high-level overview of the 4 different ways of communication in gRPC. We will come back to this later on the hands-on lecture, where we will implement each and everyone of them to get much deeper understanding.

gRPC vs REST

Now, let’s do a quick comparison of gRPC and REST to see their differences.

First, gRPC uses HTTP/2 which is, as you know, much faster than HTTP/1.1 used in REST by default. Note that today we can enable HTTP/2 in REST as well, but normally it often goes with HTTP/1.1. You can read more about how to enable HTTP/2 for REST in these articles:

• Migrate your REST API to HTTP/2
• HTTP/2 - Benefits for REST API
• HTTP/2 - Adventure in Go world

Second, gRPC uses Protocol buffer to serialize payload data, which is binary and smaller, while REST uses JSON, which is text and larger.

The API contract in gRPC is strict, and required to be clearly defined in the proto file. While in REST, it’s often loose and optional. We can define it via OpenAPI if we want, but it’s not mandatory.

Code generation is built-in in gRPC with the help of protocol buffer compiler. While in REST, we must use third-party tool like OpenAPI and Swagger.

Both gRPC and REST communications are secured with TLS/SSL.

Streaming is bidirectional in gRPC, while only 1 way request from client to server in REST.

So gRPC is better than REST for most of the things that we’ve mentioned so far. However, there’s one thing that REST is still better,

That is browser support. While REST is fully supported by all browsers, the support for gRPC is limited and required gRPC-web with a proxy layer to convert between HTTP/1 and HTTP/2.

Where to use gRPC?

So gRPC has a lot of strength, but it also has its own weaknesses. So where and when should we use gRPC in order to take full advantage of it?

As you might have guessed, microservices is where gRPC really shines, since it enables low-latency and high-throughput communication, as well as strong API contracts.

gRPC is also suitable for polyglot environments, because it provides code generations out-of-the-box for many programming languages.

Point-to-point real-time communication is also a good place for gRPC, since it has excellent support for bidirectional streaming.

And finally, gRPC is a great choice for a network-constrained environment such as mobile application (android/ios), because of its light-weight message format.

Alright, so now you’ve finished all the theory lectures of the gRPC course. Congratulations! I hope you enjoy it and I will see you in the hands-on lectures.

If you like the article, please subscribe to our Youtube channel and follow us on Twitter for more tutorials in the future.

If you want to join me on my current amazing team at Voodoo, check out our job openings here. Remote or onsite in Paris/Amsterdam/London/Berlin/Barcelona with visa sponsorship.