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

161–170 of 230 posts

Re: gRPC: The Bad Parts

#161

Post by sebastos »

jsnell wrote: post #147
sebastos wrote: post #122

Earlier quoted context omitted.

The choice to make 'unset' indistinguishable from 'default value' is such an absurdly boneheaded decision, and it boggles my mind that real software engineers allowed proto3 to go out that way. I don't get what part of your link I'm supposed to be looking at as a solution to that issue? I wasn't aware of a good solution except to have careful application logic looking for sentinel values? (which is garbage)

Yes, proto3 as released was garbage, but they later made it possible to get most proto2 behaviors via configuration. Re: your question, for proto3 an field that's declared as "optional" will allow distinguishing between set to default vs. not set, while non-"optional" fields don't.

Ah, ok! Yeah I think we've been working with an older version of protobuf for a while where that wasn't an option.

Re: gRPC: The Bad Parts

#162

Post by ranger207 »

doctorpangloss wrote: post #113
austin-cheney wrote: post #9

Yes, all of it. Google claims gRPC with protobuf yields a 10-11x performance improvement over HTTP. I am skeptical of those numbers because really it comes down to the frequency of data parsing into and out of the protobuf format. 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.

> JSON with WebSockets. Its stupid simple and still 7-8x faster than HTTP with far less administrative overhead than either HTTP or gRPC. Everyone doing what you are saying ends up reinventing parts of gRPC, on top of reinventing parts of RabbitMQ. It isn't ever "stupid simple." There are ways to build the things you need in a tightly coupled and elegant way, but what people want is Next.js, that's the coupling they…

> parts of

The counterpoint to the fact that gRPC and RabbitMQ handle whatever you're writing better than you do is that gRPC and RabbitMQ have immense amounts of complexity that you have to deal with despite the fact that you don't care about it

Re: gRPC: The Bad Parts

#163

Post by sebastos »

jakjak123 wrote: post #155
kortex wrote: post #150

Earlier quoted context omitted.

0 as a default for "no int" is tolerable, 0.0 as a default for "no float" is an absolute nightmare in any domain remotely related to math, machine learning, or data science. We dealt with a bug that for weeks was silently corrupting the results of trials pitting the performance of various algos against each other. Because a valid response was "no reply/opt out", combined with a bug in processing the "opt out" enum, a…

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 latitude to have. No more testing for 0, we'll just trust the value we parse.

[Later, in Norway, when a bug causes a client to skip filling out the LatLon message]

"Why is it flying to Africa?!?!"

------------------

Ok, after the backlash from our equatorial customers and the disaster in Norway, we've learned our lesson. We will now use a new message that lets us handle 0's, but checks that they really meant it:

message LatLonEnforced {

    optional double lat = 1;

    optional double lon = 2;
}

[At some third party dev's desk] "Oh, latitude is optional - I'll just supply longitude"

[...]

"It's throwing exceptions? But your schema says it's optional!"

------------------

Ok, it took some blood sweat and tears but we finally got this message definition licked:

message LatLonEnforced {

    optional double lat = 1; // REQUIRED. Geodetic latitude, decimal degrees

    optional double lon = 2; // REQUIRED. Geodetic longitude, decimal degrees
}

[Later, in an MR from a new hire] "Correct LatLon doc strings to reflect optional semantics"

Re: gRPC: The Bad Parts

#164

Post by BobbyJo »

abdusco wrote: post #97
ainar-g wrote: post #37

Re. bad tooling. grpcurl[1] is irreplaceable when working with gRPC APIs. It allows you to make requests even if you don't have the .proto around. [1]: https://github.com/fullstorydev/grpcurl

> make requests even if you don't have the .proto around Like this? > grpcurl -d '{"id": 1234, "tags": ["foo","bar"]}' \ grpc.server.com:443 my.custom.server.Service/Method How is that even possible? How could grpcurl know how to translate your request to binary?

I could be wrong, but it is probably using json encoding for the object body, and implementing the transport for grpc instead of http. Proto objects support json encode/decode by default in all the implementations I've seen.

https://grpc.io/blog/grpc-with-json/

Re: gRPC: The Bad Parts

#166

Post by cletus »

mike_hearn wrote: post #100
cletus wrote: post #33

Story time: the whole development of protobuf was... a mess. It was developed and used internally at Google long before it was ever open sourced. Protobuf was designed first and foremost for C++. This makes sense. All of Google's core services are in C++. Yes there's Java (and now Go and to some extent Python). I know. But protobuf was and is a C++-first framework. It's why you have features like arena allocation [1]…

There was never any licensing issue, do you think Google would depend on third party software for anything as core as the RPC system? The issue was simply that at the time, there was a culture in which "open sourcing" things was being used as an excuse to rewrite them. The official excuse was that everything depended on everything else, but that wasn't really the case. Open sourcing Stubby could certainly have been d…

> do you think Google would depend on third party software for anything as core as the RPC system?

I don't believe Google has (had?) any objections to using open source or open sourcing things but you have to remember two things:

1. Most companies weaponize open source. They use it to "commoditize their product's complements" [1]; and

2. Google3 are so deeply integrated in a way that you can't really separate some of the tech because of the dependencies on other tech. More on that below.

> Open sourcing Stubby could certainly have been done. You just open source the dependencies too

Yeah, I don't think it's always that simple. You may not own the rights to something to be able to open source it. Releasing something may trigger more viral licenses (ie GPL) to force you to open source things you don't want to or can't.

I actually went through the process of trying to import a few open source packages into Google's third party repo and there are a lot of "no nos". Like a project had to have a definite license (that was white listed by legal). Some projects liked to do silly things like having a license like "do whatever you want" or "this is public domain". That's not how public domain works BTW. And if you contacted them, they would refuse to change it even something like an MIT license, which basically emans the same thing, because they didn't understand what they were doing.

> And then Borg wasn't open sourced

This actually makes sense. Later on your suggest you were a Google SRE so you should be aware of this but to whoever else reads this: Google's traffic management was deeply integrated into the entire software stack. Load balancing, DDoS defense, inter-service routing, service deployment onto particular data centers, cells and racks and so on.

It just doesn't make sense to open source Borg without everything from global traffic management down to software network switching.

> I think only Blaze/Bazel is core infrastructure in which the open source version is actually genuinely the same codebase

I don't know the specifics but I believe that Bazel too was "Blaze inspired". I suspect it's still possible to do things in Blaze that you can't do in Bazel even though the days of Blaze BUILD files being Python rather than "Python syntax like" are long gone.

Also, Blaze itself has to integrate with various other systems than Bazel doesn' eg ObjFS, SrcFS, Forge, Perforce/Piper, MPM and various continuous build systems.

[1]: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

Re: gRPC: The Bad Parts

#167

Post by dieortin »

mike_hearn wrote: post #100
cletus wrote: post #33

Story time: the whole development of protobuf was... a mess. It was developed and used internally at Google long before it was ever open sourced. Protobuf was designed first and foremost for C++. This makes sense. All of Google's core services are in C++. Yes there's Java (and now Go and to some extent Python). I know. But protobuf was and is a C++-first framework. It's why you have features like arena allocation [1]…

There was never any licensing issue, do you think Google would depend on third party software for anything as core as the RPC system? The issue was simply that at the time, there was a culture in which "open sourcing" things was being used as an excuse to rewrite them. The official excuse was that everything depended on everything else, but that wasn't really the case. Open sourcing Stubby could certainly have been d…

What are those “really good parts” that Stubby and Borg have but their open source versions don’t?

Re: gRPC: The Bad Parts

#168

Post by hot_gril »

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…

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 too. But it's usually overkill to check the message being null, unless you added it later and need to specially deal with clients predating that change. If the client just has a bug preventing it from filling out LatLng, that's the client's problem.

The confusing part here is that even if the LatLng message is null, LatLng.lat will return 0 in some proto libraries, depending on the language. You have to specifically check if the message is null if you care. But there are enough cases where you have tons of nested protos and the 0-default behavior is actually way more convenient.

Re: gRPC: The Bad Parts

#169

Post by mig_ »

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…

Does drpc meet your needs?

https://storj.github.io/drpc/

Re: gRPC: The Bad Parts

#170

Post by tgma »

bootloop wrote: post #121
tgma wrote: post #118

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, irresp…

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.

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.

Post reply on HN