loading...
Cover image for Is gRPC better than REST? Where to use it?

gRPC vs REST Is gRPC better than REST? Where to use it?

techschoolguru profile image TECH SCHOOL Updated on ・3 min read

The complete gRPC course (15 Part Series)

1) The complete gRPC course [Protobuf + Go + Java] 2) Introduction to gRPC: why, what, how? 3 ... 13 3) HTTP/2 - The secret weapon of gRPC 4) Is gRPC better than REST? Where to use it? 5) Define a protobuf message and generate Go code 6) Protocol buffer deep-dive 7) Config Gradle to generate Java code from Protobuf 8) Generate and serialize protobuf message in Go 9) Implement unary gRPC API in Go 10) Implement server-streaming gRPC in Go 11) Upload file in chunks with client-streaming gRPC - Go 12) Implement bidirectional streaming gRPC - Go 13) gRPC reflection and Evans CLI 14) Udemy coupon 100% for the complete gRPC course 15) Use gRPC interceptor for authorization with JWT

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
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.

4 types of gRPC

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.

gRPC vs REST

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.

Where to use gRPC

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.

The complete gRPC course (15 Part Series)

1) The complete gRPC course [Protobuf + Go + Java] 2) Introduction to gRPC: why, what, how? 3 ... 13 3) HTTP/2 - The secret weapon of gRPC 4) Is gRPC better than REST? Where to use it? 5) Define a protobuf message and generate Go code 6) Protocol buffer deep-dive 7) Config Gradle to generate Java code from Protobuf 8) Generate and serialize protobuf message in Go 9) Implement unary gRPC API in Go 10) Implement server-streaming gRPC in Go 11) Upload file in chunks with client-streaming gRPC - Go 12) Implement bidirectional streaming gRPC - Go 13) gRPC reflection and Evans CLI 14) Udemy coupon 100% for the complete gRPC course 15) Use gRPC interceptor for authorization with JWT

Posted on Jun 13 by:

techschoolguru profile

TECH SCHOOL

@techschoolguru

We believe that everyone deserves a good and free education. The purpose of Tech School is to give everyone a chance to learn IT by giving free, high-quality tutorials and coding courses.

Discussion

markdown guide
 

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.