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

201–210 of 230 posts

Re: gRPC: The Bad Parts

#201

Post by pjc50 »

pjmlp wrote: post #195

I had to chuckle when I read the "Bad Tooling" section, because anyone that has had to deal with COM and DCOM, is painfully aware how much better the development experience with gRPC happens to be, and is incredible how bad the COM/DCOM tooling still is after 30 years, given its key role as Windows API, specially since Vista. Not even basic syntax highlighting for IDL files in Visual Studio, but nice goodies for doin…

> nice goodies for doing gRPC are available in Visual Studio.

Could you elaborate on this? (Heavy grpc/C# usage here and we just edit the protos)

Re: gRPC: The Bad Parts

#202

Post by pjmlp »

pjc50 wrote: post #201
pjmlp wrote: post #195

I had to chuckle when I read the "Bad Tooling" section, because anyone that has had to deal with COM and DCOM, is painfully aware how much better the development experience with gRPC happens to be, and is incredible how bad the COM/DCOM tooling still is after 30 years, given its key role as Windows API, specially since Vista. Not even basic syntax highlighting for IDL files in Visual Studio, but nice goodies for doin…

> nice goodies for doing gRPC are available in Visual Studio. Could you elaborate on this? (Heavy grpc/C# usage here and we just edit the protos)

Imagine that instead of what you do with gRPC/C#, you had to edit proto files just like using Notepad (so is the COM IDL editing experience in VS), and instead of having VS take care of the C# code generation, you either call the MIDL CLI compiler yourself, or manually integrate it on some build step, only to open the folder of generated code, and then manually merge it with your existing code inside of Visual Studio.

That is the gold experience for doing COM in C++, doing COM in C# is somehow better, but still you won't get rid of dealing with IDL files, specially now that TLB support is no longer available for .NET Core.

Quite tragic for such key technology, meanwhile C++ Builder offers a much more developer friendly experience.

Re: gRPC: The Bad Parts

#203

Post by thinkharderdev »

arp242 wrote: post #30
thinkharderdev wrote: post #17

Earlier quoted context omitted.

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

You need all the same stuff with a REST API only instead of using tooling to codegen all the boilerplate you have to write it by hand (or use janky OpenAPI code generators which, in my experience, rarely work very well).

I am increasingly annoyed by protobuf as a standalone format but given the choice to create a new API using gRPC (where I can spend five minutes writing some proto files and then codegen all the boilerplate I need for both server and client in any mainstream language) and creating it as a REST API where I have to manually code all the boilerplate and decide between a zillion different ways of doing everything I will choose gRPC 100% of the time.

Re: gRPC: The Bad Parts

#204

Post by camgunz »

IME gRPC is almost never the right balance of tradeoffs. There are (much) better tools for defining web APIs that web apps can actually use without a proxy, JSON encoding/decoding is easy to get to be real fast, and language support varies from great (Go, C++) to hmm (Java, Python). Debugging is painful, extra build steps and toolchains are annoying and flaky, dependencies are annoying, etc etc. 99% of people should probably just be using OpenAPI, and the other 1% should probably just use MessagePack.

Re: gRPC: The Bad Parts

#205

Post by arp242 »

thinkharderdev wrote: post #203
arp242 wrote: post #30

Earlier quoted context omitted.

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

You need all the same stuff with a REST API only instead of using tooling to codegen all the boilerplate you have to write it by hand (or use janky OpenAPI code generators which, in my experience, rarely work very well). I am increasingly annoyed by protobuf as a standalone format but given the choice to create a new API using gRPC (where I can spend five minutes writing some proto files and then codegen all the boil…

> You need all the same stuff with a REST API

That's just not true. A straightforward REST API is significantly simpler and less code throughout.

Re: gRPC: The Bad Parts

#206

Post by anon291 »

throwaway894345 wrote: post #85
anon291 wrote: post #36

Earlier quoted context omitted.

Depending on the use case, it's often better to just copy structs directly, with maybe some care for endianness (little-endian). But at this point, the two most popular platforms, ARM and x86, agree on endianness and most alignment. There's almost no reason why RPC should not just be send(sk, (void *)&mystruct, sizeof(struct mystructtype), 0)

Ignoring the incompatibilities in word size, endianness, etc, how does a Go or JavaScript or etc program on the receiving end know what `mystruct` is? What if you want to send string, list, map, etc data?

string, list, map, etc? You have to use an encoding scheme.

As for go / javascript? I think most languages have the ability to inspect a raw buffer.

Re: gRPC: The Bad Parts

#207

Post by throwaway894345 »

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…

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

Re: gRPC: The Bad Parts

#208

Post by throwaway894345 »

anon291 wrote: post #206
throwaway894345 wrote: post #85

Earlier quoted context omitted.

Ignoring the incompatibilities in word size, endianness, etc, how does a Go or JavaScript or etc program on the receiving end know what `mystruct` is? What if you want to send string, list, map, etc data?

string, list, map, etc? You have to use an encoding scheme. As for go / javascript? I think most languages have the ability to inspect a raw buffer.

> string, list, map, etc? You have to use an encoding scheme.

Yes, you have to use an encoding scheme like JSON or Protobufs. Dumping memory directly down the pipe as you're suggesting doesn't work.

> As for go / javascript? I think most languages have the ability to inspect a raw buffer.

No language has the ability to read a raw buffer and know what the contents are supposed to mean. There needs to be a protocol for decoding the data, for example JSON or Protobufs.

Re: gRPC: The Bad Parts

#209

Post by bunderbunder »

dcow wrote: post #176
jakjak123 wrote: post #127

Earlier quoted context omitted.

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

You can get this without gRPC, though. Any IDL with codegen will do. My journey was that of gRPC fanatic to hardened skeptic. After one too many “we’re doing it this way because that’s what Google wants (and thus my promotion needs)” decisions from gRPC “maintainers”, I can’t stomach yielding so much control to a network request framework anymore. There’s something to be said for just making http requests using your…

Avoiding request boilerplate, in and of itself, is a benefit I could take or leave. Boilerplate request/response code is boring, but not actually time-consuming to write.

What I really like about the IDL and codegen is that it makes inter-team coordination easier. Comments in the .proto file is much nicer for documentation than, e.g., Swagger docs. And it gets even better when you're negotiating protocol changes among teams. You can just start a pull request with the proposed changes to the message format and documentation, which makes the whole process so much easier (and more accurate!) than what I've experienced with negotiating protocol and API changes for REST-style services.

And then, after it gets merged, the rollout is more likely to be successful. With REST, the risk of regression is greater. You've got to contend with ill- and implicitly-defined backward compatibility semantics that are inconsistent among different JSON and request library implementations, and you've got to contend with greater risk of each team's implementation implementing the message serde code in subtly incompatible ways. protobufs and gRPC don't eliminate that risk, but they greatly reduce it.

That said, yes, you're right, it does often feel like gRPC often steps over the line from being sensibly opinionated, to being a way for Google engineers I've never even met to micro-manage me. I wouldn't say I'm a hardened skeptic yet, but I'm definitely no longer a fanatic.

Re: gRPC: The Bad Parts

#210

Post by bunderbunder »

stickfigure wrote: post #187
jakjak123 wrote: post #127

Earlier quoted context omitted.

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

> Except for our most used language, Java. The official Java implementation of grpc looks like abandonware. Out of the box the builder includes an annotation (javax.annotation.Generated) that was deprecated in 2019: https://github.com/grpc/grpc-java/issues/9179 This gives me serious pause.

I don't think it's abandonware, per se, so much as that gRPC deliberately stays way behind the times with respect to Java language versions. So that they can support enterprise users who are conservative about Java upgrades. I don't know where the Java implementation is now, but when I was using it ca. 2019, it was still officially targeting Java 7. This was after the end of public updates, but still well within Oracle's paid support period for that version.

Java 7 support is now completely over, so I'm guessing now they're targeting Java 8. This does create an annoyance for Java 9 and later users, and requires annoying workarounds for them. I don't see this as a maintainability problem, so much as a culture clash: gRPC is doing things the Google way; other people don't want to do it the Google way.

All that said, I don't think other people are wrong. This is exactly the kind of thing I was complaining about - a lot of gRPC's potential (at least for my purposes) is undermined by its status as a big complicated enterprisey Google monoculture project.

Post reply on HN