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

171–180 of 230 posts

Re: gRPC: The Bad Parts

#171

Post by sebastos »

hot_gril wrote: post #168
sebastos wrote: post #163

Earlier quoted context omitted.

message LatLon { double lat = 1; // Geodetic latitude, decimal degrees double lon = 2; // Geodetic longitude, decimal degrees } "Hmm, lat = 0, I guess they didn't fill out the message. I'll thrown an exception and handle it as an api error" [Later, somewhere near the equator] "?!?!??!" ------------------ "Ok, we learned our lesson from what happened to our customers in Sao Tome and Principe: 0.0 is a perfectly valid…

If both lat and lon are required, you don't need to throw an exception for lat=0. If you want lat=null lon=0.0 to mean something like "latitude is unknown but longitude is known to be 0.0," yeah you need optional or wrapped primitives. Edit: If a client doesn't fill out the LatLng message, that's different from lat and/or lon being null or 0. The whole LatLng message itself will be null. Proto3 always supported that…

Yeah - I think what I'm getting at though is that you want to guard against situations where somebody accidentally doesn't set one of the fields, and yet 0 is a valid value to set on that field. You could accidentally forget to fill in latitude, and that would be bad news.

Def +1 the confusingness of how you have to explicitly check for has_latlon() to make sure you're not just getting default values of a non-existent LatLon message. The asymmetry between primitive and message-type fields in having explicit presence checking is also part of my beef. It's weird to have to teach junior devs that you can do has_* checks, but only for messages.

Re: gRPC: The Bad Parts

#172

Post by pm90 »

doctorpangloss wrote: post #108
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…

> But I'd argue that the single worst part of gRPC is the impenetrability of its ecosystem I have had the opposite experience. I visit exactly two repositories on GitHub, which seem to have the vast majority of the functionality I need. > 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. Improbable did. But who…

> Improbable did. But who cares? Why do we care about compatible third party implementations? The gRPC maintainers merge third party contributions. They care. Everyone should be working on one implementation.

Until they get fired by Google.

Re: gRPC: The Bad Parts

#173

Post by hot_gril »

sebastos wrote: post #171
hot_gril wrote: post #168

Earlier quoted context omitted.

If both lat and lon are required, you don't need to throw an exception for lat=0. If you want lat=null lon=0.0 to mean something like "latitude is unknown but longitude is known to be 0.0," yeah you need optional or wrapped primitives. Edit: If a client doesn't fill out the LatLng message, that's different from lat and/or lon being null or 0. The whole LatLng message itself will be null. Proto3 always supported that…

Yeah - I think what I'm getting at though is that you want to guard against situations where somebody accidentally doesn't set one of the fields, and yet 0 is a valid value to set on that field. You could accidentally forget to fill in latitude, and that would be bad news. Def +1 the confusingness of how you have to explicitly check for has_latlon() to make sure you're not just getting default values of a non-existen…

It's safer in a way to guard against these situations, but it seems like they don't intend you to do that often because there are more downsides outweighing it. Proto2 had the "required" feature that had its own issues. Our team trusts to some degree that the user actually read the API spec, and so far it's been ok.

I can imagine message nullness being clearer in languages with optional unwrapping like JS. Like foo.bar.baz gives an error if bar is null, and if you want default-0 you use foo.bar?.baz. Idk if that's what happens though.

Re: gRPC: The Bad Parts

#174

Post by dannyobrien »

doctorpangloss wrote: post #110
leetharris wrote: post #18

Earlier quoted context omitted.

> At any rate just use JSON with WebSockets. Its stupid simple and still 7-8x faster than HTTP with far less administrative overhead than either HTTP or gRPC. gRPC is not supposed to be a standard web communication layer. There are times where you need a binary format and extremely fast serialization/deserialization. Video games are one example where binary formats are greatly preferred over JSON. But I do agree that…

> gRPC is not supposed to be a standard web communication layer. It kind of is. What do you think WebTransport in HTTP/3 is? It's basically gRPC Next. The only reason gRPC didn't make it as the standard web communication layer is because of one disastrous decision by one Chrome engineer in https://issues.chromium.org/issues/40388906 , maybe because he woke up on the wrong side of the bed.

Can you expand on this a little? I could not work out the decision from the Chrome issue you linked to.

Re: gRPC: The Bad Parts

#175

Post by xarope »

sebastos wrote: post #163
jakjak123 wrote: post #155

Earlier quoted context omitted.

I think your anecdote is rather weak with regards to the way protobuf works, but to entertain, why would a confidence of 0.0 be so different from None? 0.0 sounds very close to None for most numerical purposes if you ask me. Wait, are you using Python?

message LatLon { double lat = 1; // Geodetic latitude, decimal degrees double lon = 2; // Geodetic longitude, decimal degrees } "Hmm, lat = 0, I guess they didn't fill out the message. I'll thrown an exception and handle it as an api error" [Later, somewhere near the equator] "?!?!??!" ------------------ "Ok, we learned our lesson from what happened to our customers in Sao Tome and Principe: 0.0 is a perfectly valid…

working with gRPC allowed me to understand how go(lang)'s use of things like sql.nullstring works (pseudo'ish code}:

  astring = sql.nullstring{isNull=true, value=""}

  if astring.isNull {don't do anything}
  else {process astring.value}
So similarly, gRPC has a method called HasField, so:

  if packet.HasField(astring) {then process packet.astring}
Is it wordy? Yes. Is it elegant? Sadly, No. But does it work? Yes.

Re: gRPC: The Bad Parts

#176

Post by dcow »

jakjak123 wrote: post #127
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…

As someone in a very small company, no affiliation with any Google employees, gRPC and protobuf has been a godsend in many, many ways. My only complaint is that protoc is cumbersome af to use, and that is almost solved by buf.build. Except for our most used language, Java. Protobufs has allowed us to version, build and deliver native language bindings for a multitude of languages and platforms in a tiny team for year…

You can get this without gRPC, though. Any IDL with codegen will do. My journey was that of gRPC fanatic to hardened skeptic. After one too many “we’re doing it this way because that’s what Google wants (and thus my promotion needs)” decisions from gRPC “maintainers”, I can’t stomach yielding so much control to a network request framework anymore. There’s something to be said for just making http requests using your platform/language native tooling. Is writing request boilerplate really your dev bottleneck?

Re: gRPC: The Bad Parts

#177

Post by SrslyJosh »

FridgeSeal wrote: post #95

> Why does gRPC have to use such a non-standard term for this that only mathematicians have an intuitive understanding of? I have to explain the term every time I use it. Who are you working with lol? Nobody I’ve worked with has struggled with this concept, and I’ve worked with a range of devs, including very junior and non-native-English speakers. > Also, it doesn’t pass my “send a friend a cURL example” test for an…

>> Also, it doesn’t pass my “send a friend a cURL example” test for any web API.

> Well yeah. It’s not really intended for that use-case?

Until $WORKPLACE is invaded by Xooglers who want to gRPC all the things, regardless of whether or not there's any benefit over just using HTTPS. Internal service with dozens of users in a good week? Better use gRPC!

Re: gRPC: The Bad Parts

#178

Post by SrslyJosh »

sudorandom wrote: post #114
FridgeSeal wrote: post #95

> Why does gRPC have to use such a non-standard term for this that only mathematicians have an intuitive understanding of? I have to explain the term every time I use it. Who are you working with lol? Nobody I’ve worked with has struggled with this concept, and I’ve worked with a range of devs, including very junior and non-native-English speakers. > Also, it doesn’t pass my “send a friend a cURL example” test for an…

Hey, author here: > Why does gRPC have to use such a non-standard term for this that only mathematicians have an intuitive understanding of? I have to explain the term every time I use it. >> Who are you working with lol? Nobody I’ve worked with has struggled with this concept, and I’ve worked with a range of devs, including very junior and non-native-English speakers. This is just a small complaint. It's super easy…

> Yeah, I agree. Being easy to use isn't the indented use-case for gRPC.

Sick burn. I like it, especially since most use of gRPC seems to be cargo-culting.

Re: gRPC: The Bad Parts

#179

Post by dcow »

jscheel wrote: post #53

The tooling around gRPC with bazel when using python is so bad it’s almost impossible to work with, which is hilarious considering they both come from Google. Then I had additional problems getting it to work with Ruby. Then I had more problems getting it to work in k8s, because of load balancing with http/2. Combine those issues with a number of other problems I ran into with gRPC, and I ended up just building a sma…

At Google scale, I’m sure excruciatingly horrible builds are no worry because they’re some other team’s problem. I hope JSON-RPC eats the world.

Re: gRPC: The Bad Parts

#180

Post by blackoil »

PaulHoule wrote: post #77
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…

People complain about any system which is more complex and performant than plain ordinary JSON. Remember how Microsoft pushed "Web Services" and introduced AJAX where the last letter was supposed to be XML? Microsoft could make the case that many many features in Web Services were essential to making them work but people figured out you could just exchange JSON documents in a half-baked way and... it works.

X in AJAX stands for XMLHttpRequest, which was predecessor of fetch API. It was originally used for XML in Outlook Web but wasn't tied with it. You can send any content type with it. Also it was for async web, I don't remember it had much relation to web services. Maybe SOAP, but that wasn't MS.

In case of gRPC I believe specs are tied to protobuf but I have seen thrift implementation also.

Post reply on HN