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

21–30 of 230 posts

Re: gRPC: The Bad Parts

#21

Post by thinkharderdev »

nevir wrote: post #15
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.

> because really it comes down to the frequency of data parsing into and out of the protobuf format. Protobuf is intentionally designed to NOT require any parsing at all. Data is serialized over the wire (or stored on disk) in the same format/byte order that it is stored in memory (Yes, that also means that it's not validated at runtime) Or are you referencing the code we all invariably write before/after protobuf to…

> Protobuf is intentionally designed to NOT require any parsing at all

This is not true at all. If you have a language-specific class codegen'd by protoc then the in-memory representation of that object is absolutely not the same as the serialized representation. For example:

1. Integer values are varint encoded in the wire format but obviously not in the in-memory format

2. This depends on the language of course but variable length fields are stored inline in the wire format (and length-prefixed) while the in-memory representation will typically use some heap-allocated type (so the in-memory representation has a pointer in that field instead of the data stored inline)

Re: gRPC: The Bad Parts

#22

Post by delusional »

hamandcheese wrote: post #3

I remember being surprised at how hard it was to read the source code for grpc Java. There's an incredible amount of indirection at every turn. This made it extremely hard to get answers to questions that were undocumented. It's a shame because I know Google can put out easy to read code (see: the go standard library).

I think it's partly a culture thing. Java developers love indirection, and they're used to an ecosystem that doesn't want to be understood. An ecosystem that wants you to google whatever obtuse error message it decides to spit out, and paste whatever half thought out annotation some blog post spits back, into your code to make it work.

I've worked with people who considered anything that wasn't programmed with annotations to be "too advanced" for their use-case.

Re: gRPC: The Bad Parts

#23

Post by arp242 »

nevir wrote: post #15
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.

> because really it comes down to the frequency of data parsing into and out of the protobuf format. Protobuf is intentionally designed to NOT require any parsing at all. Data is serialized over the wire (or stored on disk) in the same format/byte order that it is stored in memory (Yes, that also means that it's not validated at runtime) Or are you referencing the code we all invariably write before/after protobuf to…

> Data is serialized over the wire (or stored on disk) in the same format/byte order that it is stored in memory

That's just not true. You can read about the wire format over here, and AFAIK no mainstream language stores things in memory like this: https://protobuf.dev/programming-guides/encoding

I've had to debug protobuf messages, which is not fun at all, and it's absolutely parsed.

Re: gRPC: The Bad Parts

#25

Post by tracker1 »

neonsunset wrote: post #10

A lot of tooling badness comes out of the fact that gRPC integration in its lingua franca, Go, requires manual wiring of protoc. I don't know why or how there isn't a one-liner option there, because my experience with using gRPC in C# has been vastly better: dotnet add package Grpc.Tools // note below and you have the client and server boilerplate (client - give it url and it's ready for use, server - inherit from ba…

Similar experiences with web services via WCF. It was in dealing with anything published that wasn't .Net where it got difficult. PHP services were not complaint with their own WSDL, similar for internal types in Java from some systems. It was often a mess compared to the C# experience, hence everyone moving towards REST or simpler documentation that was easy to one-off as needed, or use an API client.

Re: gRPC: The Bad Parts

#28

Post by PaulWaldman »

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…

This anecdote highlights scope creep and mismanagement, not a fault of gRPC.

Re: gRPC: The Bad Parts

#29

Post by jvolkman »

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.

If you use intellij, you can annotate your text protos with some header comments and unlock schema validation, completion, etc.

Re: gRPC: The Bad Parts

#30

Post by arp242 »

thinkharderdev wrote: post #17
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…

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

> What layers? Switching from REST (presumably JSON over http) to gRPC shouldn't introduce any new "layers".

Of course it does, starting with the protobufs and code generation. You say yourself in your very next reply:

"New tools sure, you need protoc or buf to build the bindings from the IDL, but what is the new DSL you need to learn?"

And the DSL is presumably protobuf, which you yourself are "increasingly annoyed" with.

Post reply on HN