Introduction:
In past (Before Web Services & REST) , RPC was a popular inter-process communication, for building client-server application in distributed systems. Main objective of RPC was to make the process of executing code on a remote machine as simple as calling a local function. Well most conventional RPC approach (CORBA) and few more, have drawbacks, such a s high complexity involved, using TCP protocol etc.gRPC, originally developed by Google, now it's open source, focuses on high performance inter-service communication technology.
gRPC, tries to overcome most of limitations of traditional RPC. It enables communication between services build using heterogeneous technologies. It is based on idea of defining service and specifying methods, that can be called remotely with their parameters and return types.
gRPC By Default, uses Protocol Buffers - Such as IDL (Interface Definition Language) to describe both the service interface and structure of payload messages.
gRPC uses HTTP2 as the Transport Protocol, a key reason for gRPC wide adaption.
- HTTP2 overcome the problem in Http 1.1, where
- Each connection can handle one request at a time. I.e. If the first request is blocked, then the next request has to wait. Therefore require to open multiple connections between client and server to support real uses cases.
- Many Headers (User-Agent, Cookie) are repeated across multiple request, which is a waste of bandwidth.
- HTTP2 overcome these problems
- All communication between client and server happens over a single TCP connection that carry number of bi-direction flows - Concept named as 'Stream', which carries one or more messages, bi-directionally. (See at the last of this post).
- Avoids Header repetition and introduces 'Header Compression' to optimize used of bandwidth.
- Also introduced new feature of sending 'Server Push Messages' without using request-response style messages.
Building MS requires lot many things to think over:
- Data Formats
- Error Patterns
- Think about data model (JSON/XML/Binary)
- EndPoints
- Load Balancing
- Efficiency
- Latency
- Interoperability
- Authentication/Authorization
- Logging
- Token Based
- Scalablity etc etc.
What if there is some framework exists to take care of all such things - There is where gRPC helps.
What is gRPC:
- It's a free and open-source framework developed by Google.
- At the core of gRPC, developer need to define the Message (REQUEST and RESPONSE) and Services using Protocol Buffers.
- Rest of gRPC code will be auto generated and as a developer, only need to provide implementation for it.
- I.e. At high level, gRPC allows to define REQUEST and RESPONSE for RPC and handles the rest for you.
- One .proto file works for over 12 programming languages (Server and Client) - And allows you to use a framework that scales to millions of RPC per seconds
- As code can be generated in any language
- gRPC globally -
- Modern, Fast, Efficient,
- Built on top of HTTP/HTTP2,
- Low latency,
- Support streaming,
- Language Independent,
- Plugged-in authentication,
- Load Balancing,
- Logging and Monitoring.
gRPC vs REST:
|
Features |
gRPC |
REST |
|
Protocol |
HTTP/2
(Fast) |
HTTP/1.1
(Slow) |
|
Payload |
Protobuf
(Binary & Small) |
JSON (Text
& Large) |
|
API
Contract |
Strict,
Required (.proto) |
Loose, Optional
(OpenAPI) |
|
Code Generation |
Built-In
(Protocol) |
3rd
Party Tools (Swagger) |
|
Security |
TLS/SSL |
TLS/SSL |
|
Streaming |
Bi-Direction |
Client
to Server (Request Only |
|
Browser
Support |
Limited
(require gRPC-Web) |
Yes |
|
|
Where to use gRPC:
- Microservices
- Low latency and High Throughput Comminication
- Strong API Contract
- Polygot Environments
- Code generation out of the box for many languages
- Point to Point Real Time Communication
- Excellent Support for Bi-Directional Streaming
- Network Constrained Environments
- Lightweight Message Format
Types of gRPC:
There are 4 types of gRPC:
- Unary: The simplest one is Unary, where the client sends 1 single request message and the server replies with 1 single response. This looks somewhat similar to the normal HTTP REST API.
- Client-Streaming - In this scenario, the client will send a stream of multiple messages or a sequence of messages to server and it expects the server to send back only 1 single response.
- Server-Streaming - Here the client sends only 1 request message, and the server replies with a stream of multiple responses. The client reads from the returned stream until there are no messages.
- Bidirectional (or bidi) streaming - This one is the most complex because client and server will keep sending and receiving multiple messages in parallel and with arbitrary order. It’s very flexible and no blocking, which means no sides need to wait for the response before sending the next messages. I.e. Server could wait to receive all client messages before sending response, it could alternately read message and then write a message or follow any other combination of read and writes.
Happy gRPC..
Arun Manglick
