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).
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.