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

111–120 of 230 posts

Re: gRPC: The Bad Parts

#111

Post by randomdata »

lanstin wrote: post #106
randomdata wrote: post #74

Earlier quoted context omitted.

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.

gRPC gives you multiplexing slow request over 1 TCP connection, which reduces all the work and memory related to 1 socket per pending request; gRPC means you don't have to put the string name of a field into the wire, which makes your messages smaller which puts less stress into the memory system and the network, assuming your field values are roughly as large as your field names.

Multiplexing is a HTTP/2 feature. But as gRPC was based on an early HTTP/2 draft, it beat HTTP/2 to the punch. Thus it is likely that HTTP/2 didn't exist at the time the statement was made and therefore HTTP/1 would have been implied.

Re: gRPC: The Bad Parts

#112

Post by lanstin »

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…

I use protobuf to specify my protocol and then generate a swagger/openAPI spec then use some swagger codegen to generate rest client libraries. For a proxy server I have to fill in some stub methods to parse the json and turn it into a gRPC call but for the gRPC server there is some library that generates a rest service listener that just calls into the gRPC server code. It works fine. I had to annotate the proto file to say what REST path to use.

Re: gRPC: The Bad Parts

#113

Post by doctorpangloss »

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 care about, and it doesn't have a message broker (neither does gRPC), and it isn't a proxy (which introduce a bajillion little problems into WebSockets), and WebSockets lifetimes don't correspond to session lifetimes, so you have to reinvent that too, and...

Re: gRPC: The Bad Parts

#114

Post by sudorandom »

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 to explain what unary means but it's often infinitely easier to use a standard industry term and not explain anything.

>> 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?

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

>> The reliance on HTTP/2 initially limited gRPC’s reach, as not all platforms and browsers fully supported it

> Again, not the intended use-case. Where does this web-browsers-are-the-be-all-and-of-tech attitude come from? Not everything needs to be based around browser support. I do agree on http/3 support lacking though.

I did say browsers here but the "platform" I am thinking of right now is actually Unity, since I do work in the game industry. Unity doesn't have support for HTTP/2. It seems that I have different experiences than you, but I still think this point is valid. gRPC didn't need to be completely broken on HTTP/1.1.

>> lack of a standardized JSON mapping

> Because JSON has an extremely anaemic set of types that either fail to encode the same semantics, or require all sorts of extra verbosity to encode. I have the opposite experience with protobuf: I know the schema, so I know what I expect to get valid data, I don’t need to rely on “look at the json to see if I got the field capitalisation right”.

I agree that it's much easier to stick to protobuf once you're completely bought-in but not every project is greenfield. Before a well-defined JSON mapping and tooling that adhered to it is is very hard to transition from JSON to protobuf. Now it's a lot easier.

>> It has made gRPC less accessible for developers accustomed to JSON-based APIs

> Because god forbid they ever had to learn anything new right? Nope, better for the rest of us to just constantly bend over backwards to support the darlings who “only know json” and apparently can’t learn anything else, ever.

No comment. I think we just have different approaches to teaching.

>> Only google would think not solving dependency management is the solution to dependency management

> Extremely good point. Will definitely be looking at Buf the next time I touch GRPC things.

I'm glad to hear it! I've had nothing but execellent experiences with buf tooling and their employees.

> GRPC is a lower-overhead, binary rpc for server-to-server or client-server use cases that want better performance and faster integration that a shared schema/IDL permits. Being able to drop in some proto files and automatically have a package with the methods available and not having to spend time wiring up url’s and writing types and parsing logic is amazing. Sorry it’s not a good fit for serving your webpage, criticising it for not being good at web stuff is like blaming a tank for not winning street races.

Without looping in the frontend (aka web) it makes the contract-based philosophy of gRPC much less compelling. Because without that, you would have to have a completely different language for contracts between service-to-service (protobuf) than frontend to service (maybe OpenAPI). For the record: I very much prefer protobufs for the "contract source of truth" to OpenAPI. gRPC-Web exists because people wanted to make this work but they built their street racer with some tank parts.

> GRPC isn’t without its issues and shortcomings- I’d like to see better enums and a stronger type system, and defs http/3 or raw quic transport.

Totally agree!

Re: gRPC: The Bad Parts

#115

Post by lanstin »

DandyDev wrote: post #56
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…

People use it - like I do - because they like the improved type safety compared to REST. We use gRPC at $dayjob and I would hate going back to the stringly typed mess that is JSON over REST or the _really_ absurdly over engineered complexity trap that is GraphQL. gRPC lets us build type safe, self-documented internal APIs easily and with tooling like Buf, most of the pain is hidden. The DSL I consider a plus. If you…

I use it because: 1. I am not writing a network API without a solid spec, and 2. I want to decouple the number of tcp connections from the amount of pending work. I don't want one wonky msg to consume many resources and I want a spike of traffic to cause more msgs to be sent to the worker pools not cause a bunch of TCP connection establishment, SSL handshakes, etc. I also find it personally offensive to send field names in each network msg, as per JSON or XML.

Re: gRPC: The Bad Parts

#116

Post by jscheel »

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

Another point of view is, don't use Bazel. In my experience, Gradle is less of a headache and well supported.

For python? Gradle doesn't really support python.

Re: gRPC: The Bad Parts

#117

Post by kodablah »

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.

For the longest time (up until earlier this year[0]), you couldn't even get the proto details from a gRPC error. IME GP is correct, there are so many caveats to gRPC implementations that unless it is a prioritized, canonical implementation it will be missing things. It seems there are tons of gRPC libraries out there that fell behind or were missing features that you don't know until you need them (e.g. I recently had to do a big lift to implement HTTP proxy support in Tonic for a project).

0 - https://github.com/grpc/grpc-dotnet/issues/303

Re: gRPC: The Bad Parts

#118

Post by tgma »

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, irrespective of protobuf, is relying on trailers for status code, which hindered its adoption in the context of web browser without an edge proxy that could translate gRPC and gRPC-web wire formats. That alone IMO hindered the universal applicability and adoption quite a bit.

Re: gRPC: The Bad Parts

#119

Post by neonsunset »

kodablah wrote: post #117
neonsunset wrote: post #54

Earlier quoted context omitted.

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.

For the longest time (up until earlier this year[0]), you couldn't even get the proto details from a gRPC error. IME GP is correct, there are so many caveats to gRPC implementations that unless it is a prioritized, canonical implementation it will be missing things. It seems there are tons of gRPC libraries out there that fell behind or were missing features that you don't know until you need them (e.g. I recently ha…

> unless it is a prioritized, canonical implementation it will be missing things

Perhaps. But for now, such canonical implementation (I assume you are referring to the Go one?) is painful to access and has all around really bad user experience. I'm simply pointing out that more ecosystems could learn from .NET's example (or just adopt it) rather than continuing to exist in their own bubble, and more engineers could have zero tolerance to the tooling with bad UX as it becomes more popular.

Now, with that said, I do not think gRPC is ultimately good, but I do think it's less bad than many other "language-agnostic" options - I've been burned badly enough by Avro, thanks. And, at least within .NET, accessing gRPC is even easier than OpenAPI-generated clients. If you care about overhead, Protobuf will always be worse than bespoke solutions like RKYV or MemoryPack.

I'm looking forward to solutions inspired by gRPC yet made specifically on top of HTTP/3's WebTransport, but that is something that is yet to come.

Re: gRPC: The Bad Parts

#120

Post by randomdata »

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…

> It's super easy to explain what unary means but it's often infinitely easier to use a standard industry term and not explain anything.

What's the standard term? While I agree that unary isn't widely known, I don't think I have ever heard of any other word used in its place.

> gRPC didn't need to be completely broken on HTTP/1.1.

It didn't need to per se (although you'd lose a lot of the reason for why it was created), but as gRPC was designed before HTTP/2 was finalized, it was still believed that everyone would want to start using HTTP/2. HTTP/1 support seemed unnecessary.

And as it was designed before HTTP/2 was finalized, it is not like it could have ridden on the coattails of libraries that have since figured out how to commingle HTTP/1 and HTTP/2. They had to write HTTP/2 from scratch in order to implement gRPC, so supporting HTTP/1 as well would have greatly ramped up the complexity.

Frankly, their assumption should have been right. It's a sorry state that they got it wrong.

Post reply on HN