There is a player in the market to make your microservices talk to each other lightning fast and super efficient, gRPC.
Its an RPC (Remote Procedure Call) platform developed by Google.
Its repetitively being compared to REST API, a pillar of web programming for a long time.
What is gRPC?
gRPC is an abbreviation for Google Remote Procedure Call. gRPC utilizes Protobuf for serialization and also it is pluggable with any form of serialization.
gRPC offers two essential types for client server communication.
Unary
Essentially these are synchronous requests made to the gRPC server with a single request that blocks until a response is received.
Streaming
Streaming is really powerful and can be accomplished in three different configurations: client pushing messages to a stream; server pushing messages to a stream; or bidirectional, where client and server are both sending data in two streams in the same method.
In all cases the client initiates the RPC method. This is how gRPC works.
Source Credit: Medium
gRPC has started encroaching on REST APIs territory, it seems there are good reasons for it! Lets find out.
Why is gRPC better than REST API?
Lets dive into the technological differences between the two.
Protobuf vs. JSON
The very first difference between REST and gRPC is format of the payload.
REST APIs accept and return JSON, in a textual format. You can compress JSON, but then you lose the benefit of a textual format that you can easily expect.
Whereas, gRPC uses Protobuf, a very efficient and packed format.
Google’s Protocol Buffers, are a better choice than JSON for encoding data.
HTTP/2 vs. HTTP 1.1
REST heavily depends on HTTP 1.1
gRPC uses the newer HTTP/2 protocol.
HTTP2 is basically an advanced version of HTTP1. All the issues with HTTP1 are fixated in HTTP2 with some additional features.
In HTTP1, multiplication of separate objects increases the load on web servers significantly and slows down page load times for users.
HTTP2, uses multiplexed streams. A single HTTP/2 TCP connection can support many bidirectional streams.
Messages vs. Resources and Verbs
it’s been very difficult to implement REST properly, reason is that it’s actually quite challenging to map business logic and operations into the strict REST world.
The conceptual model used by gRPC is to have services with clear interfaces and structured messages for requests and responses. It will allow gRPC to automatically generate client libraries for you.
Related Resource : REST vs. gRPC: Battle of the APIs
Conclusion
In the world of microservices, gRPC will become dominant very soon. However, REST will still be around for a long time as it excels for publicly exposed APIs and for backward compatibility reasons.
Because of the advancements gRPC is enabled with, it stands at a lot better position than REST APIs.
Read about how businesses leverage microservices here.
