<story><title>gRPC: The Bad Parts</title><url>https://kmcd.dev/posts/grpc-the-bad-parts/</url></story><parent_chain><item><author>bunderbunder</author><text>All good points. But I&amp;#x27;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&amp;#x27;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.&lt;p&gt;And a lot of these features arguably have a poor cost&amp;#x2F;benefit tradeoff for anyone who isn&amp;#x27;t trying to solve Google problems. Or they introduce painful constraints such as not being consumable from client-side code in the browser.&lt;p&gt;I keep wishing for an alternative project that only specifies a simpler, more compatible, easier-to-grok subset of gRPC&amp;#x27;s feature set. There&amp;#x27;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.</text></item></parent_chain><comment><author>jakjak123</author><text>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.&lt;p&gt;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.</text></comment>
<story><title>gRPC: The Bad Parts</title><url>https://kmcd.dev/posts/grpc-the-bad-parts/</url></story><parent_chain><item><author>bunderbunder</author><text>All good points. But I&amp;#x27;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&amp;#x27;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.&lt;p&gt;And a lot of these features arguably have a poor cost&amp;#x2F;benefit tradeoff for anyone who isn&amp;#x27;t trying to solve Google problems. Or they introduce painful constraints such as not being consumable from client-side code in the browser.&lt;p&gt;I keep wishing for an alternative project that only specifies a simpler, more compatible, easier-to-grok subset of gRPC&amp;#x27;s feature set. There&amp;#x27;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.</text></item></parent_chain><comment><author>PaulHoule</author><text>People complain about any system which is more complex and performant than plain ordinary JSON. Remember how Microsoft pushed &amp;quot;Web Services&amp;quot; and introduced AJAX where the last letter was supposed to be XML?&lt;p&gt;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.</text></comment>