gRPC, a Cloud Native Computing Foundation (CNCF) project, is a complete RPC framework originally created by Google in 2015. By default, it works on top of HTTP/2 and uses Protocol Buffers as its Interface Definition Language and serialization mechanism, but can work with other transport protocols or schemas.
It can run on any environment, as it comes with native support for most modern programming languages. Although it works even on browsers, it is most commonly used to create services in and across data centers.
gRPC main abstraction is the channel. A channel represents a gRPC connection between a client and a server, and is basically an HTTP/2 connection. This is fundamental, as thanks to HTTP/2, gRPC natively supports concurrent, bidirectional persistent connections.
HTTP/2 takes the concept of persistent connection to the next level creating a new abstraction: streams, which are a series of related messages (called frames). There are two types of streams:
- Short-lived - also known as unary streams, as in a traditional request-response architecture.
- Long-lived - they keep a persistent connection, either from or to the client, that use the network resources more efficiently by allowing concurrent stream messages.
In gRPC, each rpc (endpoint), either unary or long-lived, has its own stream, making a total of 4 possible rpc types:
- Unary - As a
GETin REST. - Server streaming - Similar to unary, but a stream of messages are sent back to the client.
- Client streaming - As a unary, but a stream of messages are sent from the client to the server. Typically the server will send its message when the client is done.
- Bidirectional streaming - Initiated by the client, creates two independent streams.
As defined by Google, Protocol buffers are a language-neutral, platform-neutral extensible mechanism for serializing structured data. They allow for service definition, as an IDL, as well as a strongly-typed payload definition. This is helpful to make an efficient usage of the network, because messages are serialized to binary format.
As any RPC style, a gRPC API can be defined using either a resource-oriented or an action-oriented approach. However, it is recommended following a resource-oriented approach, so that it can easily be mapped as a REST (see gRPC Transcoding).