gRPC

gRPC is a modern, open source, high-performance remote procedure call (RPC) framework. By default, gRPC uses Protocol Buffers (Protobuf) as the Interface Definition Language (IDL) for describing both the service interface and the structure of the payload messages. In gRPC, a client application can directly call a method on a server application on a different machine as if it were a local object, making it easier for you to create distributed applications and services. As in many RPC systems, gRPC is based on the idea of defining a service, specifying the methods that can be called remotely with their parameters and return types. The server implements the interface and runs a gRPC server to handle client calls; the client has a stub that provides the same methods as the server.

The following are the main design principles of gRPC:

  • gRPC can be created on all common development platforms and in many different languages.

  • It is designed to work on devices with low CPU and memory capabilities, such as Android [1] and iOS devices, MicroPython boards and browsers [2] [3].

  • It is licensed under Apache License 2.0 and uses open standards such as HTTP/2 and Quick UDP Internet Connections (QUIC).

  • gRPC is interoperable and can therefore also be used in the LoRaWan (Long Range Wide Area Network), for example.

  • The individual layers can be developed independently of each other. For example, the transport layer (OSI layer 4) can be developed independently of the application layer (OSI layer 7).

  • gRPC supports various serialisation formats, including Protocol Buffers (Protobuf), JSON [4], XML/HTML and Thrift)

  • Asynchronous and synchronous (blocking) processing are supported in most languages.

  • Streaming of messages in a single RPC call is supported.

  • gRPC allows protocol extensions for security, healtch checks, load balancing, failover, etc.

digraph grpc_concept { rankdir="LR"; graph [fontname = "Calibri", fontsize="16", penwidth="5px", overlap=false]; node [fontname = "Calibri", fontsize="16", style="bold", penwidth="5px"]; edge [fontname = "Calibri", fontsize="16", style="bold", penwidth="5px"]; tooltip="gRPC concept"; // C++ service subgraph "cluster_cpp_service" { label="C++ Service"; fontcolor="#2D7BFD"; shape=box; style= "rounded"; color="#2D7BFD"; "grpc_server" [ label="gRPC server", fontcolor="#640FFB" shape=box, style= "rounded", color="#640FFB" ]; } // Python-Stub subgraph cluster_python_client { label="Python client"; fontcolor="#2D7BFD"; shape=box; style= "rounded"; color="#2D7BFD"; grpc_python_stub [ label="gRPC Python-Stub", fontcolor="#640FFB" shape=box, style= "rounded", color="#640FFB" ]; } // Android-Java-Stub subgraph cluster_android_java_client { label="Android-Java client"; fontcolor="#2D7BFD"; shape=box; style= "rounded"; color="#2D7BFD"; grpc_android_java_stub [ label="gRPC Android-Java-Stub", fontcolor="#640FFB" shape=box, style= "rounded", color="#640FFB" ]; } grpc_python_stub -> grpc_server [label="Proto-Request", fontcolor="#640FFB", color="#7539FC"] grpc_android_java_stub -> grpc_server [label="Proto-Request", fontcolor="#640FFB", color="#7539FC"] grpc_server -> grpc_python_stub [label="Proto-Response", fontcolor="#300099", color="#300099"] grpc_server -> grpc_android_java_stub [label="Proto-Response", fontcolor="#300099", color="#300099"] }

Starting with an interface definition in a .proto file, gRPC provides Protocol Compiler plugins that generate Client- and Server-side APIs. Both synchronous and asynchronous communication is supported in most languages. gRPC also supports streaming of messages in a single RPC call. The gRPC protocol abstractly specifies the communication between clients and servers:

  1. First the stream is started by the client with a mandatory Call Header

    1. followed by optional Initial-Metadata

    2. followed by optional Payload Messages.

    The contents of Call Header and Initial Metadata are sent as HTTP/2 headers compressed with HPACK.

  2. The server answers with an optional Initial-Metadata

    1. followed by Payload Messages

    2. and terminated with mandatory Status and optional Status-Metadata.

    Payload Messages are serialised into a byte stream fragmented into HTTP/2 frames. Status and Trailing-Metadata are sent as HTTP/2 trailing headers.

Unlike FastAPI, however, the gRPC API cannot simply be tested on the command line with cURL. If necessary, you can use grpcurl. This requires that the gRPC server supports the GRPC Server Reflection Protocol. Usually Reflection should only be available in the development phase. Then you can call grpcurl, e.g. with:

$ grpcurl localhost:9111 list

See also