My biggest complaint with gRPC is proto3 making all nested type fields optional while making primitives always present with default values. gRPC is contract based so it makes no sense to me that you can't require a field. This is especially painful from an ergonomics viewpoint. You have to null check every field with a non primitive type.
gRPC: The Bad Parts
41–50 of 230 posts
Re: gRPC: The Bad Parts
#42Something I didn’t see listed was the lack of a package manager for protos. For example if I want to import some common set of structs into my protos, there isn’t a standardized or wide spread way to do this. Historically I have had to resort to either copying the structs over or importing multiple protoc generated modules in my code (not in my protos). If there was a ‘go get’ or ‘pip install’ equivalent for protos,…
It is mentioned under the "Bad tooling" section
Re: gRPC: The Bad Parts
#43My biggest complaint with gRPC is proto3 making all nested type fields optional while making primitives always present with default values. gRPC is contract based so it makes no sense to me that you can't require a field. This is especially painful from an ergonomics viewpoint. You have to null check every field with a non primitive type.
If I remember correctly the initial version allowed required fields but it caused all sorts of problems when trying to migrate protos because a new required fields breaks all consumers almost by definition. So updating protos in isolation becomes tricky.
The problem went away with all optional fields so it was decided the headache wasn't worth it.
Re: gRPC: The Bad Parts
#44in my latest project I actually needed an rpc library that was hardware accelerated and I was surprised gRPC doesn't do RDMA for example. why is that?
Re: gRPC: The Bad Parts
#45> Bad tooling
Lolwut. This is what was always said about ASN.1 and the reason that this wheel has to be reinvented periodically.
Re: gRPC: The Bad Parts
#46I remember being surprised at how hard it was to read the source code for grpc Java. There's an incredible amount of indirection at every turn. This made it extremely hard to get answers to questions that were undocumented. It's a shame because I know Google can put out easy to read code (see: the go standard library).
The generated C++ interfaces to gRPC are also filled with an incredible amount of indirection and unnecessary concepts. I'd say it's a "bad at writing complex things simply" culture rather than being Java-specific.
Re: gRPC: The Bad Parts
#47Re: gRPC: The Bad Parts
#48My biggest complaint with gRPC is proto3 making all nested type fields optional while making primitives always present with default values. gRPC is contract based so it makes no sense to me that you can't require a field. This is especially painful from an ergonomics viewpoint. You have to null check every field with a non primitive type.
RPC/proto is for transport.
Required/validation is for application.
Re: gRPC: The Bad Parts
#49All good points. But I'd argue that the single worst part of gRPC is the impenetrability of its ecosystem. And I think that, in turn, is born of complexity. The thing is so packed with features and behaviors and temporal coupling and whatnot that it's difficult to produce a compatible third-party implementation. That means that, in effect, the only true gRPC implementation is the one that Google maintains. Which, in turn, means that the only languages with good enough gRPC support to allow betting your business on it are the ones that Google supports.
And a lot of these features arguably have a poor cost/benefit tradeoff for anyone who isn't trying to solve Google problems. Or they introduce painful constraints such as not being consumable from client-side code in the browser.
I keep wishing for an alternative project that only specifies a simpler, more compatible, easier-to-grok subset of gRPC's feature set. There's almost zero overlap between the features that I love about gRPC, and the features that make it difficult to advocate for adopting it at work.
Re: gRPC: The Bad Parts
#50A lot of this kind of criticism rubs me the wrong way, especially complaining about having to use words or maths concepts, or having to learn new things. That's often not really a statement on the inherent virtue of a tool, and more of a statement on the familiarity of the author.
I don't want to sound flippant, but if you don't want to learn new things, don't use new tools :D