it's just my opinion when I think of grpc, I really appreciate your article. I just compared with the following scenario of the rest you don't need any schema you don't have to stay fixed with a schema from the client side. any HTTP request you send does not need to have a prevalidated schema In the case of grpc, you will need a proto file for each grpc service you want to call to the backend. I meant this when I said bulky. From Browser support I mean, there is no direct web API that can call the grpc. To call the grpc you will have to follow something like the following client -> rest endpoint -> grpc endpoint This was the state when I read about this technology and explored it. I will appreciate it if you can add some resources which can contradict the web API issue. Thanks for a great article. Happy Coding

This is pretty good. I think as a technology, we should focus on the pros and cons, and why was it introduced. I think it was introduced to keep a single library for each client and server, so the changes are centralized, unlike REST. Pros: It is fast It uses http2 under the hood Single library for each client and server maintained by google Cons Protobuf makes the client bulky No direct use of JSON, it won't make sense for the client to know the schema No browser support YET It is new and growing Proxy Support, as any application deployed is not just simple client and server so, the proxy or gateway layer should understand the protocol as well I believe this is a pretty good piece of technology for microservices intercommunication as it is fast and can reduce the latency in communication.