FWIW I never worked at Google and I used protobuf / gRPC extensively at work and in nearly all of my side projects. Personally, I think overall it's great. I do wish trailers were an optional feature though.
gRPC: The Bad Parts
71–80 of 230 posts
Re: gRPC: The Bad Parts
#72I don't understand why there isn't an HTTP/1 mode for gRPC. Would cover the super common use case of client-to-server calls. Give people who already have your typical JSON-over-HTTP API something that's the same except more efficient and with a nicer API spec. You know what's ironic, Google AppEngine doesn't support HTTP/2. Actually a lot of platforms don't.
The streaming message transfer modes are the main thing that make it difficult.
Re: gRPC: The Bad Parts
#73Earlier quoted context omitted.
Won't work if your struct has any pointers in it.
I'd recommend not doing that then. Of course the same is true if you coerce a pointer to an int64 and store it in a protobuf.
It's not the pointers themselves so much as what they're typically used for. How would you do dynamic sizing? Imagine sending just a struct of integer arrays this way, you'd have to either know their sizes ahead of time or just be ok with sending a lot of empty bits up to some max size. And recursive structures would be impossible.
You could get around this with a ton of effort around serdes, but it'd amount to reinventing ASN1 or Protobuf.
Re: gRPC: The Bad Parts
#74Yes, 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.
> Google claims gRPC with protobuf yields a 10-11x performance improvement over HTTP. That... doesn't make any sense, since gRPC is layered on top of HTTP. There must be missing context here.
gRPC was based on a HTTP draft that predated the standardization of HTTP/2, so presumably that statement was said about HTTP/1. HTTP/2 may not have existed at the time it was asserted.
Re: gRPC: The Bad Parts
#75I don't understand why there isn't an HTTP/1 mode for gRPC. Would cover the super common use case of client-to-server calls. Give people who already have your typical JSON-over-HTTP API something that's the same except more efficient and with a nicer API spec. You know what's ironic, Google AppEngine doesn't support HTTP/2. Actually a lot of platforms don't.
The streaming message transfer modes are the main thing that make it difficult.
Streaming seems like it'd work without too much effort. It'd be less efficient for sure, but it's also not a very common use case.
Re: gRPC: The Bad Parts
#76My 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.
proto2 allowed both required fields and optional fields, and there were pros and cons to using both, but both were workable options.
Then proto3 went and implemented a hybrid that was the worst of both worlds. They made all fields optional, but eliminated the introspection that let a receiver know if a field had been populated by the sender. Instead they silently populated missing fields with a hardcoded default that could be a perfectly meaningful value for that field. This effectively made all fields required for the sender, but without the framework support to catch when fields were accidentally not populated. And it made it necessary to add custom signaling between the sender and receiver to indicate message versions or other mechanisms so the receiver could determine which fields the sender was expected to have actually populated.
Re: gRPC: The Bad Parts
#77All 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.
Re: gRPC: The Bad Parts
#78Insisting a particularly exotic flavor of HTTP(2) is its most severe design flaw, I think. Especially, as it could have worked in an agnostic manner, e.g. on top WebSockets.
Re: gRPC: The Bad Parts
#79Earlier quoted context omitted.
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.
proto2 allowed both required fields and optional fields, and there were pros and cons to using both, but both were workable options. Then proto3 went and implemented a hybrid that was the worst of both worlds. They made all fields optional, but eliminated the introspection that let a receiver know if a field had been populated by the sender. Instead they silently populated missing fields with a hardcoded default that…
You can now detect field presence in several cases: https://protobuf.dev/programming-guides/field_presence/#pres...
This is very solid with message types, but for basic types you can add `optional field` if needed as well (essentially making the value nullable)
Re: gRPC: The Bad Parts
#80Yes, 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.
> 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 meant for backend microservices among other things, and it's still painful for that for the reasons the article describes, all of which could've been fixed or avoided. Internally Google doesn't even use gRPC, they use something similar that has better internal support according to https://news.ycombinator.com/item?id=17690676
I also don't see what'd stop it from being used generally for websites calling the backend API. Even if you don't care about the efficiency (which is likely), it'd be nice to get API definitions built in instead of having to set up OpenAPI.