Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

gRPC: The Bad Parts

kmcd.dev

Post reply on HN
Print view View original

131–140 of 230 posts

Re: gRPC: The Bad Parts

#131

Post by hot_gril »

sebastos wrote: post #123
hot_gril wrote: post #60

Earlier quoted context omitted.

proto3 added support for optional primitives sorta recently. I've always been happy without them personally, but it was enough of a shock for people used to proto2 that it made sense to add them back.

Just out of curiosity, what domain were you working in where "0.0" and "no opinion" were _always_ the same thing? The lack of optionals has infuriated me for years and I just can't form a mental model of how anybody ever found this acceptable to work with.

Not really one domain in particular, just internal services in general. In many cases, the field is intended to be required in the first place. If not, surprisingly 0 isn't a real answer a lot of the time, so it means none or default: any kind of numeric ID that starts at 1 (like ticket numbers), TTLs, error codes, enums (0 is always UNKNOWN). Similarly with empty strings.

I have a hard time thinking of places I really need both 0 and none. The only example that comes to mind is building room numbers, in some room search message where we wanted null to mean wildcard. In those cases, it's not hard to wrap it in a message. Probably the best argument for optionals is when you have a lot of boolean request options where null means default, but even then I prefer instead naming them such that the defaults are all false, since that's clearer anyway.

It did take some getting used to and caused some downstream changes to how we design APIs. I think we're better for it because the whole null vs 0 thing can be tedious and error-prone, but it's very opinionated.

Re: gRPC: The Bad Parts

#132

Post by cyberax »

sudorandom wrote: post #99
cyberax wrote: post #59

I'm surprised the author doesn't mention ConnectRPC: https://connectrpc.com/ It solves ALL the problems of vanilla gRPC, and it even is compatible with the gRPC clients! It grew out of Twirp protocol, which I liked so much I made a C++ implementation: https://github.com/Cyberax/twirp-cpp But ConnectRPC guys went further, and they built a complete infrastructure for RPC. Including a package manager (buf.build), integr…

Author here: I definitely should have been more explicit for my love of connectrpc, buf, protovalidate, etc. I do mention ConnectRPC but maybe not as loud as I could have. I definitely try to avoid confessing my love for ConnectRPC in every post, but sometimes it's hard not to because they've made such good strategic decisions that just make sense and round out the ecosystem so well.

My fault, I did read the article but I overlooked the ConnectRPC mention.

Re: gRPC: The Bad Parts

#133

Post by jakjak123 »

neonsunset wrote: post #54
bunderbunder wrote: post #49

All 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…

It is possible to do quite well, as demonstrated by .NET. Edit: and, if I remember correctly, gRPC tooling for it is maintained by about 1-3 people that are also responsible for other projects, like System.Text.Json. You don't need numbers to make something that is nice to use, quite often, it makes it more difficult even.

.NET looks quite good, as well as Swift actually. I have most experience with Java, and those are almost as nice as the .NET bindings. I have also used Go quite a bit, and they are pretty much awful. It takes so much practice and knowledge to use them well in Go.

Re: gRPC: The Bad Parts

#134

Post by jakjak123 »

sudorandom wrote: post #104
lalaithion wrote: post #20

We use the textproto format extensively at work; it's super nice to be able to define tests of your APIs by using .textpb inputs and golden .textpb outputs. We have so many more tests using this method than if we manually called the APIs by in a programming language for each test case, and I wouldn't want to use JSON for test inputs, since it lacks comments.

Author here: Sorry that I was so harsh on textproto. You are right that it has some strengths over JSON... I'm actually a fan of JSONC for this reason. It does limit you on tooling... but so does textproto, right? I think the bigger thing that I'm worried about is that gRPC has so many mandatory features that it can become hard to make a good implementation in new languages. To be honest there are some languages wher…

Yeah, the feature bloat makes it a hurdle to make some good quality implementations. I mostly stayed in Java for years. They are quite good. grpc-web is ok I guess, protobuf-ts are great, swift came along as nice, then I have always been saddened by how awful they are in Go. You will get terrible enums, terrible one-ofs, the interceptors and service registration are very awkward.

Re: gRPC: The Bad Parts

#135

Post by jakjak123 »

mattboardman wrote: post #41

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.

It was a little weird at first, but if you just read the 1.5 pages of why protobuf decided to work like this it made perfect sense to me. It will seem over complicated though to web developers who are used to being able to update all their clients at a whim at any moment.

Re: gRPC: The Bad Parts

#136

Post by jakjak123 »

hot_gril wrote: post #60
mattboardman wrote: post #41

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.

proto3 added support for optional primitives sorta recently. I've always been happy without them personally, but it was enough of a shock for people used to proto2 that it made sense to add them back.

Same, I rarely felt a need for this distinction.

Re: gRPC: The Bad Parts

#137

Post by silverlyra »

dudus wrote: post #43
mattboardman wrote: post #41

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.

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.

If you want to precisely capture when a field must be present (or will always be set on the server), the field_behavior annotation captures more of the nuance than proto2's required fields: https://github.com/googleapis/googleapis/blob/master/google/...

You could (e.g.) annotate all key fields as IDENTIFIERs. Client code can assume those will always be set in server responses, but are optional when making an RPC request to create that resource.

(This may just work in theory, though – I’m not sure which code generators have good support for field_behavior.)

Re: gRPC: The Bad Parts

#138

Post by jakjak123 »

sebastos wrote: post #123
hot_gril wrote: post #60

Earlier quoted context omitted.

proto3 added support for optional primitives sorta recently. I've always been happy without them personally, but it was enough of a shock for people used to proto2 that it made sense to add them back.

Just out of curiosity, what domain were you working in where "0.0" and "no opinion" were _always_ the same thing? The lack of optionals has infuriated me for years and I just can't form a mental model of how anybody ever found this acceptable to work with.

Like nearly every time, empty string and 0 for integers can be treated the same as "no value" if you think about it. Are you sending data or sending opinions? Usually to force a choice, you would make a enum or a one-of where the zero-value means the client has forgotten to set it and it can be modelled as a api error. Whether the value was actually on the wire or not is not really that important.

Re: gRPC: The Bad Parts

#139

Post by [deleted] »

skywhopper wrote: post #14

The worst part of all is that most people don’t need gRPC, but use it anyway. It’s a net addition of complexity and you’re very likely not getting the actual benefits. I’ve seen countless simple REST APIs built with language-native tooling burned to the ground to be replaced with layers of gRPC trash that requires learning multiple new tools and DSLs, is harder to troubleshoot and debug, and ultimately tends to force…

[deleted]

Re: gRPC: The Bad Parts

#140

Post by jakjak123 »

hot_gril wrote: post #131
sebastos wrote: post #123

Earlier quoted context omitted.

Just out of curiosity, what domain were you working in where "0.0" and "no opinion" were _always_ the same thing? The lack of optionals has infuriated me for years and I just can't form a mental model of how anybody ever found this acceptable to work with.

Not really one domain in particular, just internal services in general. In many cases, the field is intended to be required in the first place. If not, surprisingly 0 isn't a real answer a lot of the time, so it means none or default: any kind of numeric ID that starts at 1 (like ticket numbers), TTLs, error codes, enums (0 is always UNKNOWN). Similarly with empty strings. I have a hard time thinking of places I real…

I had the same experience. It was a bit awkward for 6 months, but down the line we learned to design better apis, and dealing with nullable values are tedious at best. Its just easier knowing that a string or integer will _never_ cause a nullpointer.
Post reply on HN