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 gRP...
For further actions, you may consider blocking this person and/or reporting abuse
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.