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

211–220 of 230 posts

Re: gRPC: The Bad Parts

#211

Post by shepherdjerred »

metadat wrote: post #129
doctorpangloss wrote: post #109

Earlier quoted context omitted.

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.

Maven is one of my favorite package managers. It's not as fancy as npm, cargo, go, etc., but it works consistently well and I never have to fight it.

Re: gRPC: The Bad Parts

#212

Post by hot_gril »

kaba0 wrote: post #191
hot_gril wrote: post #87

Earlier quoted context omitted.

Java is on life support as a language, but the ecosystem is strong, that's why it has all these weird features via annotations. And people who use Java are just trying to get stuff done like everyone else.

How is it on life support, when it’s by far the biggest server-side language, running basically every top companies’ business critical infrastructure? Also, annotations are just metaprogramming, which can be tastefully applied.

Like I said, the ecosystem is strong. The language's design hasn't aged well, so nowadays any Java code I see in prod has 1-4 annotations above every class and method to get around the limitations of the language. Similar to how some C code will rely heavily on macros.

Re: gRPC: The Bad Parts

#213

Post by stairlane »

ergl wrote: post #42
stairlane wrote: post #31

Something I didn’t see listed was the lack of a package manager for protos. For example if I want to import some common set of structs into my protos, there isn’t a standardized or wide spread way to do this. Historically I have had to resort to either copying the structs over or importing multiple protoc generated modules in my code (not in my protos). If there was a ‘go get’ or ‘pip install’ equivalent for protos,…

It is mentioned under the "Bad tooling" section

Oh my mistake, must have missed that.

Re: gRPC: The Bad Parts

#214

Post by stairlane »

JeffMcCune wrote: post #39
stairlane wrote: post #31

Something I didn’t see listed was the lack of a package manager for protos. For example if I want to import some common set of structs into my protos, there isn’t a standardized or wide spread way to do this. Historically I have had to resort to either copying the structs over or importing multiple protoc generated modules in my code (not in my protos). If there was a ‘go get’ or ‘pip install’ equivalent for protos,…

https://buf.build/ is this, no?

Thanks for sharing! Yes things like this would help solve our problems.

Re: gRPC: The Bad Parts

#215

Post by bitzun »

My main problems with grpc are threefold:

- The implementation quality and practices vary a lot. The python library lacks features that the go library has because they are philosophically opposed to them. Protobuf/grpc version pinning between my dependencies has broken repeatedly for me.

- If you are a services team, your consumers inherit a lot of difficult dependencies. Any normal json api does not do this, with openapi the team can use codegen or not.

- The people who have been most hype to me in person about grpc repeat things like "It's just C structs on the wire" which is completely fucking wrong, or that protobuf is smaller than json which is a more situational benefit. My point being their "opinion" is uninformed and band-wagoning.

This article gave me some new options for dunking on grpc if it's recommended.

Re: gRPC: The Bad Parts

#216

Post by cryptonector »

throwaway894345 wrote: post #91
cryptonector wrote: post #45

> Bad tooling Lolwut. This is what was always said about ASN.1 and the reason that this wheel has to be reinvented periodically.

It can be true for both ASN.1 and gRPC? Moreover, definitions of "bad" can vary.

Before inventing a new serialization protocol it would be good to first study the field and pick an existing protocol that ticks all the right boxes, and if the tooling isn't very good then write new tooling -- you'd have to write new tooling for a new protocol anyways, but if you can find a good enough existing one then you don't also have to write a spec, thus saving you a lot of time.

Re: gRPC: The Bad Parts

#217

Post by DandyDev »

throwaway894345 wrote: post #207
DandyDev wrote: post #56

Earlier quoted context omitted.

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…

> People use it - like I do - because they like the improved type safety compared to REST. You don't need a binary format just to get type safety. JSONSchema, OpenAPI, etc exist after all. > But in this case the DSL is OpenAPI, which is an error prone mess of YAML or JSON specifications. They might not be pretty, but they're not particularly error prone (the specs themselves are statically checked).

YAML in any form is error prone and hard to write. Protobuf - for all its warts - is much easier to write And much more type safe.

But let’s just agree to disagree here. You do you and build REST APIs, while I’ll stick to gRPC

Re: gRPC: The Bad Parts

#218

Post by throwaway894345 »

DandyDev wrote: post #217
throwaway894345 wrote: post #207

Earlier quoted context omitted.

> People use it - like I do - because they like the improved type safety compared to REST. You don't need a binary format just to get type safety. JSONSchema, OpenAPI, etc exist after all. > But in this case the DSL is OpenAPI, which is an error prone mess of YAML or JSON specifications. They might not be pretty, but they're not particularly error prone (the specs themselves are statically checked).

YAML in any form is error prone and hard to write. Protobuf - for all its warts - is much easier to write And much more type safe. But let’s just agree to disagree here. You do you and build REST APIs, while I’ll stick to gRPC

I’m not anti-protobuf; it’s just overkill for type safety. But yeah, use what you want.

Re: gRPC: The Bad Parts

#219

Post by kortex »

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?

Yes it was python but that has nothing to do with it. Same would happen in go, rust, R, or matlab.

Correct answers: 1.0, 0.0, 1.0

Confidence from algo: 1.0, 0.0, n/a

Confidence on the wire: 1.0, 0.0, 0.0

Score after bug: 66%

Score as it ought to be scored: 100%

It was enough to make several algorithms which were very selective in the data they would attempt to analyze (think jpg vs png images) went from "kinda crap" in the rankings to "really good"

Re: gRPC: The Bad Parts

#220

Post by mardifoufs »

dannyobrien wrote: post #174
doctorpangloss wrote: post #110

Earlier quoted context omitted.

> gRPC is not supposed to be a standard web communication layer. It kind of is. What do you think WebTransport in HTTP/3 is? It's basically gRPC Next. The only reason gRPC didn't make it as the standard web communication layer is because of one disastrous decision by one Chrome engineer in https://issues.chromium.org/issues/40388906 , maybe because he woke up on the wrong side of the bed.

Can you expand on this a little? I could not work out the decision from the Chrome issue you linked to.

I think this blog post provides the context for that chromium discussion:

https://carlmastrangelo.com/blog/why-does-grpc-insist-on-tra...

(Somewhere in the middle of the article)

Post reply on HN