protobuffers are no end of pain for me at work.

Yes, the guarantee of no breaking changes in an API is wonderful. Everything else sucks.

Not being able to use JSON to test your api? sucks.

Having to convert the changed .proto files to a new library for your language (gem for ruby in my case) and then have your system use that instead of the latest release (because you haven't tested it yet) sucks.

A terrible ruby library written by people who were obviously not ruby devs (it makes FooServiceService classes for example)? sucks.

hoop-jumping to force a breaking change in something you thought was good, but isn't and hasn't been released yet? Sucks

horribly degraded iteration loops on new functionality? sucks

not being able to host it anywhere that doesn't support HTTP2 (Heroku)? sucks

Unless you're working on something at google scale and the performance difference and bandwidth savings are actually noticeable RUN FOR THE HILLS. Protobuffers will bring you nothing but pain.

Take a look at Twirp (https://github.com/twitchtv/twirp) open sourced by TwitchTv. It's a lot lighter weight than gRPC. It does use Protobufs but addresses some of the concerns you mentioned, such as being able to test with JSON payloads, works over HTTP 1.1 and HTTP/2, good client libraries, and doesn't require a proxy.

They address your concerns in more detail in the Twirp release announcement (2018) - https://blog.twitch.tv/en/2018/01/16/twirp-a-sweet-new-rpc-f...