loading...

re: Is gRPC better than REST? Where to use it? VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Hi Friends! Thanks for detailed article :) However, I dare disagree with you, pardonne moi s'il vous plait :) I'm working with various services ...
 

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.

code of conduct - report abuse