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