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

121–130 of 230 posts

Re: gRPC: The Bad Parts

#121

Post by bootloop »

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.

Re: gRPC: The Bad Parts

#122

Post by sebastos »

fisian wrote: post #69
dudus wrote: post #43

Earlier 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.

That decision seems practical (especially at Google scale). I think the main problem with it, is that you cannot distinguish if the field has the default value or just wasn't set (which is just error prone). However, there are solutions to this, that add very little overhead to the code and to message size (see e.g. [1]). [1]: https://protobuf.dev/programming-guides/dos-donts/

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)

Re: gRPC: The Bad Parts

#123

Post by sebastos »

hot_gril wrote: post #60
mattboardman wrote: post #41

My 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.

proto3 added support for optional primitives sorta recently. I've always been happy without them personally, but it was enough of a shock for people used to proto2 that it made sense to add them back.

Just out of curiosity, what domain were you working in where "0.0" and "no opinion" were _always_ the same thing? The lack of optionals has infuriated me for years and I just can't form a mental model of how anybody ever found this acceptable to work with.

Re: gRPC: The Bad Parts

#124

Post by neonsunset »

lanstin wrote: post #105
jamesmunns wrote: post #65

Earlier quoted context omitted.

Do all of your platforms have the same word width? The same -fshort-enums settings? Do you know that none of your data structures include pointers? Do all of your systems use the same compiler? Compiler version? I agree it will usually work, but this becomes an ABI concern, and it's surprisingly common to have ABI mismatches on one platform with the items I've noted above.

I've seen wire protocols that had junk for the alignment buffering in such structs. And I've seen people have to do a whole lot of work to make the wire protocol work on a newer compiler/platform. Also, the whole point of a network protocol being documented is that it decouples the interface (msgs over a network) from the implementation (parsing and acting on msgs). Your v1 server might be able to just copy the read…

Go's GC wasn't really made with throughput maximization in mind. It's a language that doesn't scale that well to take advantage of beefy nodes and has weak compiler. I suppose the Google's vision for it is to "crank the replica count up". gRPC servers based on top of ASP.NET Core, Java Vert.X and Rust Thruster will provide you with much higher throughput on multi-core nodes.

https://github.com/LesnyRumcajs/grpc_bench/discussions/441

Re: gRPC: The Bad Parts

#125

Post by epgui »

usrnm wrote: post #57
epgui wrote: post #50

A lot of this kind of criticism rubs me the wrong way, especially complaining about having to use words or maths concepts, or having to learn new things. That's often not really a statement on the inherent virtue of a tool, and more of a statement on the familiarity of the author. I don't want to sound flippant, but if you don't want to learn new things, don't use new tools :D

Sending a request and getting a response back is not a new concept, it's about as old as computer networks in general, and gRPC is the only framework that refers to this concept as "unary". This is the original argument from the article and I tend to agree with it

Monads and functors are nothing new either, but that doesn’t mean giving them that name was a bad idea.

Moreover, the term “unary” is used to distinguish from other, non-unary options: https://grpc.io/docs/what-is-grpc/core-concepts/

Re: gRPC: The Bad Parts

#127

Post by jakjak123 »

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 years now, without a single fault. We have the power to refactor and design our platform and apis in a way that we never had before. We love it.

Re: gRPC: The Bad Parts

#128

Post by austin-cheney »

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…

but what people want is Next.js,

What people? Developers? This is why I will not do that work anymore. Don't assume to know what I want based upon some tool set or tech stack that you find favorable. I hate (HATE HATE) talk of tech stacks, the fantasy of the developer who cannot write original software, who does not measure things, and cannot provide their own test automation. They scream their stupidity for all the world to hear when they start crying about reinventing wheels, or some other empty cliche, instead of just delivering a solution.

What I want is two things:

1. Speed. This is not an assumption of speed. Its the result of various measurements in different execution contexts.

2. Less effort. I want to send a message across a network... and done. In this case you have some form of instruction or data package and then you literally just write that to the socket. That is literally 2 primitive instructions without abstractions like ex: socket.write(JSON.parse(thing));. It is without round trips, without headers, without anything else. You are just done.

Re: gRPC: The Bad Parts

#129

Post by metadat »

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.

Gradle is an anti-pattern. Just stick with Maven and live a happy life.

As someone who's used Gradle tons, 6 months ago I wrote in detail about why not gradle:

https://news.ycombinator.com/item?id=38875936

Gradle still might less bad than Bazel, though.

Re: gRPC: The Bad Parts

#130

Post by hot_gril »

nly wrote: post #103
hot_gril wrote: post #73

Earlier quoted context omitted.

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

A lot of protocols in low latency trading systems just have fixed maximum size strings and will right pad with NUL or ASCII space characters. Packed structs with fixed size fields, little endian integers and fixed point is heaven to work with.

I can see that in niche situations, particularly if you have a flat structure and uniform hardware. Cap'n Proto is also a way to do zero-parsing, but it has other costs.
Post reply on HN