Advent 2021: gRPC
This blog is part of the 24 posts long series "Advent 2021":
- Advent 2021: Intro (December 01, 2021)
- Advent 2021: C++ (December 02, 2021)
- Advent 2021: C# (December 03, 2021)
- Advent 2021: Python (December 04, 2021)
- Advent 2021: Go (December 05, 2021)
- Advent 2021: TypeScript (December 06, 2021)
- Advent 2021: CMake (December 07, 2021)
- Advent 2021: Django (December 08, 2021)
- Advent 2021: Angular (December 09, 2021)
- Advent 2021: Flask (December 10, 2021)
- Advent 2021: gRPC (December 11, 2021)
- Advent 2021: GraphQL (December 12, 2021)
- Advent 2021: XML & JSON (December 13, 2021)
- Advent 2021: Matplotlib, Pandas & Numpy (December 14, 2021)
- Advent 2021: Linux (December 15, 2021)
- Advent 2021: Ansible (December 16, 2021)
- Advent 2021: SQLite (December 17, 2021)
- Advent 2021: Catch2 (December 18, 2021)
- Advent 2021: Zstandard (December 19, 2021)
- Advent 2021: ZFS (December 20, 2021)
- Advent 2021: Thunderbird (December 21, 2021)
- Advent 2021: Visual Studio Code (December 22, 2021)
- Advent 2021: Blender (December 23, 2021)
- Advent 2021: Open source (December 24, 2021)
Another framework that I’ve started using this year is gRPC. I’ve been following its development for many years, but never really had an use case until earlier this year. For those of you who are wondering what gRPC is: It’s a remote procedure call library, which is about as unexciting as things get. What it does is allow communication between applications over HTTP/2, while abstracting away how arguments are actually sent over the wire, or how the endpoint is found. From your perspective you write an interface file and implement it, and at runtime you point at a web endpoint and it just works. It’s supposedly what Google uses internally for lots of services, and more recently Microsoft has decided to phase out their .NET RPC mechanism (WCF) so it’s also quite stable these days.
These days we split applications into loosely-coupled micro-services, which requires a high-performance, easy to use RPC mechanism. While you can use REST or GraphQL or other web techniques, those are not ideal if you’re working with tons of small requests, you want low-overhead processing, or you need to pass binary data around (JSON is quite horrible to send binary data). Especially for binary data the encoding/decoding overhead of JSON makes it quickly unusable, and there’s no way to stream large amounts of data using a REST interface directly. Of course you can fall back to sending it directly (after all, you can download/upload files using HTTP), but that means having multiple separate paths which quickly gets complicated.
With gRPC, it’s all unified and from both sides it looks like “normal” function calls. What I really liked about gRPC is how easy it is to get started, and how quickly you can build a reasonably scalable application with it. In my case I used a C# gRPC server process and a client written in Go. You define your interface as a “protocol buffer”, which is also used as the transport mechanism, and the gRPC/protocol buffer compiler will produce stubs that you just need to fill in. I’ve tried RPC before using a couple different mechanisms and so far, gRPC is the easiest-to-use tool I found for it. If you need RPC and you don’t have super specific requirements, give it a go!