gRPC brings speed to the API
On the web, we move data back and forth in various formats. Most of them are text-based, e.g. XML or JSON. gRPC from Google uses a different approach: it encodes transmitted data in binary form. This cannot be decoded by humans without auxiliary programs, but is obvious for computers - and reduces the amount of data transferred.
Why gRPC?
gRPC is an alternative to REST or GraphQL which is ideal when performance is crucial. A typical area of application is communication between microservices. But gRPC is also ideally suited for an API, especially with many clients. Here, gRPC scores with the fact that the client service for data exchange can be generated without additional effort.
Highlights:
- Top speed: response times are reduced thanks to HTTP/2. Streaming speeds up the transmission of large amounts of data, such as high-resolution images, considerably.
- Contract based: The interface definition is recorded in a data model that the client and server must fulfill. Services and types can be generated from this, which saves time and minimizes errors.
- Platform-independent: gRPC does not create any unnecessary dependencies as it does not require a specific programming language or platform.
Maximum performance through HTTP/2 and Protobuf
Performance has top priority. This is primarily made possible by two fundamental techniques on which gRPC is based:
HTTP/2
gRPC utilizes the advantages of HTTP/2the further development of the protocol for data transmission on the web. It allows binary-coded content and simplifies the bundling of data packets. HTTP/2 is already built into all modern browsers.
Protobuf
gRPC relies on the binary data format Protobuf, with the full name Protocol Buffers. Binary data is less extensive than text-structured data and can therefore be transferred more quickly.
Comfort is taken care of
Non-human-readable sounds unusual at first - but when working with gRPC this does not matter, as appropriate tools are available. It offers similar advantages to GraphQ with a slightly different approach:
- The logic is programmed in the server, the service for data transfer in the client is generated from it - with types, of course.
- Communication between client and server is based on a contract: both know exactly what data they need to send and receive.
- There are "reserved fields" for dealing with breaking changes (deprecations).