[tgma]

gRPC is deliberately designed not to be dependent on protobuf for its message format. It can be used to transfer other serialization formats. However, the canonical stub generator, which is not hard to replace at all, assumes proto so when people hear gRPC they really think of Protobuf over gRPC. Most of the complaints should be directed at protobuf, with or without gRPC.

The primary misfeature of gRPC itself, irrespective of protobuf, is relying on trailers for status code, which hindered its adoption in the context of web browser without an edge proxy that could translate gRPC and gRPC-web wire formats. That alone IMO hindered the universal applicability and adoption quite a bit.

[bootloop]

Do you know of an example where this is done? I didn't know that and we are currently using a customized wire format (based on a patched Thrift), so I thought gRPC wouldn't be an option for us.

[tgma]

I have done it in proprietary settings. Nothing off the top of my head. The gRPC libraries themselves are pretty straightforward. You just need to use thrift IDL parser to output stubs that use gRPC under the hood.

The C++ one may be slightly more challenging to replace because extra care is needed to make sure protobuf message pipeline is zero-copy. Other languages are more trivial.

One place to start would be to look at the gRPC protoc plugin and see how it’s outputting code and do something similar. Pretty lean code.

[jakjak123]

This is the true design issue with gRPC as I see it. It would be way bigger without this. I love protobuf though, gRPC is just alright. At least gRPC makes it so much simpler to build powerful automation and tooling around it than the wild west of randomly created 'json'-ish REST-ish APIs.