I found gRPC to be exciting when I was writing something in Go. The tooling around that is pretty decent and it sets a certain expectation about how it works.

I found gRPC to be exciting when I was writing something in Go. The tooling around that is pretty decent and it sets a certain expectation about how it works. Then I had to write a client in a different language, and the generated code was utterly intuitive. gRPC itself adds extensions to Protobuf to handle code-gen nuances but of course they're deployed in Go-land, not relevant-language-land. That's a small niggle that's easily solved one way or another. What was frustrating was that the `protobuf` CLI could handle language extensions, but you couldn't make use of that without a hell of a lot of faff. If you want to add a gRPC client to your Rails app you can't use the protobuf CLI, that you might already have.... you have to add a gem that includes a different version of the protobuf CLI that is guaranteed to be not compatible. Even the command and its args aren't compatible. When I found myself working against that I just gave up. It's a solution that sounds elegant, but you're going to get a feature out of the door much quicker if you steer away from that layer altogether. There's nothing wrong with an ad-hoc HTTP API if you're confident about the interface. Technical purity isn't technical excellence and nor is it user value. Just like K8S, you're not gonna need RPC on the web unless you can justify the scale and have the firepower to handle it.