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:
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.
Top comments (5)
I am not sure I understand the comparison.
REST is an architectural principle. REST is about various things, such as representing a set of resources with a common interface, for example the HTTP verb set. REST doesn't care, I think, about the serialisation format or the transport.
How is gRPC even comparable to REST? Are you trying to compare gRPC with HTTP + JSON media formatters? Or is the intention something else?
Apologies if I have misunderstood the article.
Hi Frank, you're right, I actually meant to compare gRPC vs normal HTTP JSON API.
Hi Friends!
Thanks for detailed article :)
However, I dare disagree with you, pardonne moi s'il vous plait :)
I'm working with various services and microservices, and overall backend stuff for last 7 years probably and I always was unhappy with GRPC and SOAP. Compared to REST they are too "heavy-weight", and in Java/Go most libraries for them require code generation. Protobuf is insanely clumsy with its own compiler.
Main "advantages" of gRPC are really not always working:
gRPC allows save throughput (what you mean by lightweight messages) but we all know very important principle "don't optimize until you are sure it is necessary" - so often it's preferable to design microservices exchanging JSON and only if we once find it don't suit us, switch to protobuf where needed. Moreover data transfer is cheap nowadays (and becomes cheaper each year) so cases when we really need to save on transfer are rare even in bigdata world (and also we can compress json when transferring).
"strict API contract" is often more burden rather than advantage as it makes harder updating message format, requiring recompiling all participants.
and obvious disadvantage is that if microservice uses REST/JSON to talk to other microservice - the same endpoint could be utilized by frontend; however talking to grpc endpoint though possible, but rarely done from UI.
So, honestly, I'm afraid there could be not too much audience for whom gRPC is important (especially here on DEV where many people are frontenders or doing some lightweight full-stack).
Hi Rodion,
Thanks for your comment!
I'm not a fan of SOAP either. But gRPC is a completely different thing.
I don't know why you think gRPC is heavy-weight. Code generation is one of the most important and valuable thing in gRPC. In microservices world, it saves us a lot of time because we don't need to write a lot of boilerplate codes to allow services to talk to each other. And also, it is strongly typed, so no need to worry about converting JSON to internal data types.
Perhaps you haven't dealt with a very high-traffic system, so you haven't seen the advantages of gRPC over REST/JSON. It's not just about the smaller data size, it's also much faster and comes with bidirectional-streaming out-of-the-box.
API evolution is always a hard problem, and that applies to REST/JSON as well. We have to introduce API versioning in REST, and it also require clients to update if it's a breaking change. With gRPC, protobuf has some standard rules (such as reserved fields) to ensure the forward and backward compatibility of the API.
Your point about reusing the same endpoint for UI is not really valid. We choose the appropriate tools for the right situation. In a big microservices backend, there would be much more internal/private endpoints than public ones, and gRPC would be more suitable for inter-service communication.
While on the front-end side, sometimes we can even introduce different APIs for web and mobile applications, because mobile users tend to have limited/slower bandwidth than web users. If your system has markets in some developing countries in Asia or Africa, you will see it :) As already stated in the post, gRPC is not well supported on the web browser yet, but it's still great for mobile applications.
After 4 years working with Microservices + HTTP (REST + JSON) APIs, I completely agree on your post. I have used most of my dev time, just fixing inter service communication, fixing HTTP clients (error handling, headers name, query params, etc..) instead of working on actual business value. Strict APIs contract are required in the Microservices world; open/optional APIs just work on personal-weekend-hobby projects.