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 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).
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.
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:
First the stream is started by the client with a mandatory
followed by optional
followd by optional
The contents of
Initial Metadataare sent as HTTP/2 headers compressed with
The server answers with an optional
and terminated with mandatory
Payload Messages are serialised into a byte stream fragmented into HTTP/2 frames.
Trailing-Metadataare 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