Hacker News Reader

gRPC is also a 300lb gorilla of a framework for communication and has huge problems with versioning if you aren't "running at HEAD".

View on HN

My original comment might have given the impression that I was some gRPC guru when in reality I’ve only played with it very briefly.

What are the versioning problems with it? I was under the impression that it was actually designed from the start to be fairly flexible with regards to changing API methods etc

Well I wasn't referring to API versioning, I was referring to the actual lib versioning. All of Google runs basically at HEAD and nearly all of their libraries reflect this. In a distributed system, if you update one of the GRPc library versions, you need to update all of them otherwise you can run into weird failures.

That might be true, but at least when I was at Google, people were not building and releasing their software to pick up HEAD of libraries they depended on. Some binaries running in production could be quite old and seemed to communicate with newer builds just fine. (I suppose if there was a problem someone would have built a new version, though.)

The real question IMHO is "does the library change impact the protocol itself"? Because last time I checked, gRPC the protocol didn't evolve that fast. Now, gRPC-REST bridges are a different thing...

That’s a skinny gorilla.

Reply on news.ycombinator.com