I would say gRPC is fine as long as you don’t have the following:
1) work on a team where people will make assumptions about how gRPC works because they will be wrong, for example see the article, but more generally it can be quite obtuse.
2) want to be able to easily debug over the wire information
3) expect there to be a wealth of stack overflow knowledge to be able to debug weird incompatibilities between go and JavaScript implementations
4) schema that you expect to rapidly change over time and/or versioning of said schema to avoid strange results. It’s extremely difficult to track these changes on a large codebase.
If you were at a shop that used grpc a lot, would you not have tools ready to go that can turns the protobuf back into text?
I've often thought how odd it is that the world is spending time and energy parsing things into text formats and back, when its just two computers communicating...making more work for themselves and the entire internet backbone....just because we can't be bothered to use a simple tool when debugging over the wire.
That is exactly what we do. You can write a python tool in like a dozen lines to cast to and from.
There is also a way to use one of the built in protobuf tools to do it but you also have to point at the proto files yourself.
I think there are other advantages to text protocols besides debugging on the wire, namely ease of composing tools. Streams of text is extremely versatile and economic for many workflows. Of course you lose that ease once you start embedding binary data.
If on-the-wire readability is important you can always opt for a different marshaling method, like JSON (or even roll your own). Yes it's some extra work but not a showstopper if that's the only downside of gRPC/Protobufs.
1) work on a team where people will make assumptions about how gRPC works because they will be wrong, for example see the article, but more generally it can be quite obtuse.
2) want to be able to easily debug over the wire information
3) expect there to be a wealth of stack overflow knowledge to be able to debug weird incompatibilities between go and JavaScript implementations
4) schema that you expect to rapidly change over time and/or versioning of said schema to avoid strange results. It’s extremely difficult to track these changes on a large codebase.