Why 'REST' when you can 'gRPC'

gRPC stands for gRPC Remote Procedure Call. It's an open-source framework by Google for remote procedure calls based on protocol buffers. Request/response messages and the API definition are created in .proto files. These proto files are then shared with the clients for stub generation.

gRPC is much faster than REST

gRPC is fast becoming a modern standard for building microservices. It is based on Google's protocol buffers, which are Google's language-neutral, platform-neutral, extensible mechanism for serialized and structured data. Since the serialized binary data is closer to machine language as compared to CPU intensive processing of human-readable JSON format, the gRPC is much faster than the REST protocol.

Another factor that contributes to the speed of gRPC is the fact that it works on the HTTP/2 protocol. The single duplex connection coupled with compressed headers help reduce network latency. Also, the server-side push feature of HTTP/2 help build streaming APIs when using gRPC.

Low network latency and the fact that Google's protocol buffers can be used across different programming platforms make gRPC a very good alternative for building microservices. But REST is still the de-facto option for web applications as the good old JSON is javascript friendly. Plugins for building gRPC clients will take time to mature and become popular. So an ideal architecture would be to use REST between client and the API gateway/front-facing microservices and use gRPC for microservice to microservice communication (as shown in the diagram above)

gRPC POC