Introduction
gRPC is initially developed by Google. It is a high performance, open source RPC framework and is based on a client-server model of remote procedure calls.
With help of gRPC client application can directly call methods on a server application as if it was a local object.
Strengths of gRPC
gRPC is offering many benefits in certain operations. Some of the gRPC strengths are as follows:
Performance
gRPC offers better performance and API-security than REST+JSON communication as it uses Protobuf and HTTP/2. Protobuf serializes the messages on the server and client sides quickly, resulting in small and compact message payloads. HTTP/2 scales up the performance ranking via server push, multiplexing, and header compression.
Streaming
gRPC supports client- or server-side streaming semantics, which are already incorporated in the service definition. This makes it much simpler to build streaming services or clients. A gRPC service supports different streaming combinations through HTTP/2:
- Unary (No Streaming)
- Client-to-server streaming
- Server-to-Client streaming
- Bi-directional streaming
Code Generation
The prime feature of gRPC methodology is the native code generation for client/server applications. gRPC frameworks use protoc compiler to generate code from the .proto file. It can produce server-side skeletons and client-side network stubs.
Interoperability and Productivity
gRPC tools and libraries are designed to work with multiple platforms and programming languages, including Java, JavaScript, Ruby, Python, Objective-C, C#, and more. As it automatically generate the skeletons it helps developers to focus more on business logic.
Weaknesses of gRPC
gRPC also have some downsides that we need to be aware of before choosing it for developing applications.
Limited Browser Support
As gRPC heavily uses HTTP/2, it is impossible to call a gRPC service from a web browser directly. No modern browser provides the control needed over web requests to support a gRPC client. Therefore, a proxy layer and gRPC-web are required to perform conversions between HTTP/1.1 and HTTP/2.
Non-human Readable Format
Protobuf compresses gRPC messages into a non-human readable format.
No Edge Caching
gRPC specification doesn’t make any provisions for cache semantics between server and client.
Comparison of different Serialization schemes
| XML | JSON | Proto | |
|---|---|---|---|
| Human Readable Data | Yes | Yes | No |
| Browser consumable | Yes | Yes | No |
| JS Support | Yes | Yes | No |
| Data Security | Can be eavesdropped and decoded | Can be eavesdropped and decoded | Hard to decode without knowing the schema |
| Processing Speed | < JSON | < Proto | > XML, JSON |
| Interfaces For RPC | No | No | Yes |
| Validations | Hand parsing and Validations are required | Hand parsing and Validations are required | Validations are easy with Keywords |
Working with Protocol Buffers
By default, gRPC uses Protocol Buffers, Google’s open source mechanism for serializing structured data. Protocol Buffer data is structured as messages, where each message contains a series of name-value pairs called fields. We can also use other data formats such as JSON.
We will see how Protocol Buffers works:
As step-1 we define the structure for the data we want to serialize in a proto file, i.e. is an text file with a .proto extension. For example:
message Player{
string name = 1;
int32 id = 2,
bool iscaptain = 3
}
In above example 1,2,3 denotes the sequence for the fields.
As Step-2 We will use the Protocol Buffer compiler protoc to generate data access classes in our preferred language from previously generated proto definition.
This step provide accessors for each field and methods to serialize/parse the entire structure to/from raw bytes. So for instance, if we chose C#, running the compiler
will generate the Player class, that we can use in our application to populate, serialize, and retrieve Player protocol buffer messages.
Finally, we define gRPC services in ordinary proto files, with RPC method parameters and return types specified as protocol buffer messages. For example:
service PlayerService{
rpc GetPlayer(PlayerRequest) returns (PlayerResponse){}
}
message PlayerRequest{
int32 id = 1;
}
message PlayerResponse {
int32 id = 1;
string name = 2;
bool iscaptain = 3;
}
Protocol buffer versions
Currently most application uses Protocol Buffers version 3(proto3), which has slightly simplified syntax and supports more languages. Proto3 is currently available in Java, C++, Python, Objective-C, C#, Ruby, and JavaScript from the protocol buffers GitHub repo. Proto3 also helps to avoiding compatibility issues with proto2 clients talking to proto3 servers and vice versa.
Different Types of RPC:
Simple RPC(Unary RPC):
This is a most simple type of RPC where the client sends a single request and gets back a single response.
Server streaming RPC:
A server-streaming RPC is similar to a unary RPC, except that the server returns a stream of messages including status details (status code and optional status message) and trailing metadata in response to a client’s request.
Client streaming RPC:
A client-streaming RPC is similar to a unary RPC, except that the client sends a stream of messages to the server instead of a single message. The server responds with a single message along with its status details and optional trailing metadata.
Bidirectional streaming RPC:
In a bidirectional streaming RPC, the call is initiated by the client invoking the method and the server receiving the client metadata, method name, and deadline.
The server can choose to send back its initial metadata or wait for the client to start streaming messages.
Here the client and server can read and write messages in any order. For example,
A server can wait until it has received all of a client’s messages before writing its messages or,
the server gets a request, then sends back a response, then the client sends another request based on the response, and so on.
RPC Termination/Complition
The RPC call complitions for client and server are managed in their own environment. It may happen that an RPC finishes successfully on the server, but fails on the client side may be because the responses arrived to client after the specified deadlines/timeouts limit.
Authentication
gRPC is designed to work with a variety of authentication mechanisms.
The following authentication mechanisms are built-in to gRPC:
1. SSL/TLS: gRPC has SSL/TLS integration and promotes the use of SSL/TLS (with or without Google token-based authentication)
to authenticate the server and encrypt all the data exchanged between the client and the server.
2. ALTS: gRPC supports ALTS as a transport security mechanism, if the application is running on Google Cloud Platform (GCP).
3. Token-based authentication with Google
gRPC also provides a simple authentication API that lets you provide all the necessary authentication information as Credentials when creating a channel or making a call.
Why we use gRPC?
The main usage scenarios:
- Low latency, highly scalable, distributed systems.
- Developing mobile clients which are communicating to a cloud server.
- Designing a new protocol that needs to be accurate, efficient and language independent.
- Layered design to enable extension eg. authentication, load balancing, logging and monitoring etc.