[bunderbunder]

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 turn, means that the only languages with good enough gRPC support to allow betting your business on it are the ones that Google supports.

And a lot of these features arguably have a poor cost/benefit tradeoff for anyone who isn't trying to solve Google problems. Or they introduce painful constraints such as not being consumable from client-side code in the browser.

I keep wishing for an alternative project that only specifies a simpler, more compatible, easier-to-grok subset of gRPC's feature set. There's almost zero overlap between the features that I love about gRPC, and the features that make it difficult to advocate for adopting it at work.

[jakjak123]

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.

[dcow]

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 platform/language native tooling. Is writing request boilerplate really your dev bottleneck?

[bunderbunder]

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.

[dcow]

Maybe hardened skeptic is HN hyperbole. I tend to avoid adding it to every project I touch these days, though.

[stickfigure]

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

[bunderbunder]

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.

[doctorpangloss]

> But I'd argue that the single worst part of gRPC is the impenetrability of its ecosystem

I have had the opposite experience. I visit exactly two repositories on GitHub, which seem to have the vast majority of the functionality I need.

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

Improbable did. But who cares? Why do we care about compatible third party implementations? The gRPC maintainers merge third party contributions. They care. Everyone should be working on one implementation.

> features arguably have a poor cost/benefit tradeoff for anyone who isn't trying to solve Google problems.

Maybe.

We need less toil, less energy spent reinventing half of Kubernetes and half of gRPC.

[pm90]

> Improbable did. But who cares? Why do we care about compatible third party implementations? The gRPC maintainers merge third party contributions. They care. Everyone should be working on one implementation.

Until they get fired by Google.

[PaulHoule]

People complain about any system which is more complex and performant than plain ordinary JSON. Remember how Microsoft pushed "Web Services" and introduced AJAX where the last letter was supposed to be XML?

Microsoft could make the case that many many features in Web Services were essential to making them work but people figured out you could just exchange JSON documents in a half-baked way and... it works.

[blackoil]

X in AJAX stands for XMLHttpRequest, which was predecessor of fetch API. It was originally used for XML in Outlook Web but wasn't tied with it. You can send any content type with it. Also it was for async web, I don't remember it had much relation to web services. Maybe SOAP, but that wasn't MS.

In case of gRPC I believe specs are tied to protobuf but I have seen thrift implementation also.

[arccy]

> I keep wishing for an alternative project that only specifies a simpler, more compatible, easier-to-grok subset of gRPC's feature set. There's almost zero overlap between the features that I love about gRPC, and the features that make it difficult to advocate for adopting it at work.

Perhaps connect: https://connectrpc.com/

[neonsunset]

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.

[kodablah]

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

[neonsunset]

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

[svaha1728]

No disrespect to the other developers on the team, but James Newton-King is no ordinary developer.

[jakjak123]

.NET looks quite good, as well as Swift actually. I have most experience with Java, and those are almost as nice as the .NET bindings. I have also used Go quite a bit, and they are pretty much awful. It takes so much practice and knowledge to use them well in Go.

[pixl97]

>It is possible to do quite well, as demonstrated by {one of the other largest companies in the world}

FTFY

[mig_]

Does drpc meet your needs?

https://storj.github.io/drpc/