11 ms·

gRPC: The Bad Parts

228 points by temp_praneshp 2y ago

emrah 2y ago
While one can't refute the existence of the mentioned warts, they are not a big concern practically. We use gRPC in our Partner SDK[0] and Connector SDK[1]. [0] https://fivetran.com/docs/partner-built-program https://fivetran.com/docs/partner-built-program [1] https://fivetran.com/docs/connectors/connector-sdk https://fivetran.com/docs/connectors/connector-sdk
tempest_ 2y ago
One of my favourite bits is having to pass a json string to the python library to configure a service. To this day I am not entirely sure it is adhering to the config
- ycombinatrix 2y ago
  same in java
hamandcheese 2y ago
I remember being surprised at how hard it was to read the source code for grpc Java. There's an incredible amount of indirection at every turn. This made it extremely hard to get answers to questions that were undocumented. It's a shame because I know Google can put out easy to read code (see: the go standard library).
- hinkley 2y ago
  Sass was the first code generator I ever met that produced decent output. I’d been coding for 15 years at that point. Less is the second one. That’s the end of this story. There are basically two people in the world who have demonstrated that they can be trusted to generate code that isn’t an impenetrable quagmire of pain and confusion. I doubt it’s an accident that both emitted declarative output rather than imperative, but I would be happy to be proven wrong.
- ot 2y ago
  > It's a shame because I know Google can put out easy to read code (see: the go standard library). My guess is that the difference is that go is managed by a small group of engineers that have strong opinions, really care about it, and they have reached "fuck you level", so they can prioritize what they think is important instead of what would look good on a promo packet.
- delusional 2y ago
  I think it's partly a culture thing. Java developers love indirection, and they're used to an ecosystem that doesn't want to be understood. An ecosystem that wants you to google whatever obtuse error message it decides to spit out, and paste whatever half thought out annotation some blog post spits back, into your code to make it work. I've worked with people who considered anything that wasn't programmed with annotations to be "too advanced" for their use-case.
  - hot_gril 2y ago
    Java is on life support as a language, but the ecosystem is strong, that's why it has all these weird features via annotations. And people who use Java are just trying to get stuff done like everyone else.
    - za3faran 2y ago
      Java is doing quite well.
    - kaba0 2y ago
      How is it on life support, when it’s by far the biggest server-side language, running basically every top companies’ business critical infrastructure? Also, annotations are just metaprogramming, which can be tastefully applied.
      - hot_gril 2y ago
        Like I said, the ecosystem is strong. The language's design hasn't aged well, so nowadays any Java code I see in prod has 1-4 annotations above every class and method to get around the limitations of the language. Similar to how some C code will rely heavily on macros.
        kaba0 2y ago
        That’s not due to the language, but due to the business domain (I assume web development). In this domain almost every framework, regardless of language, will heavily use metaprogramming, see django, etc.
- cjensen 2y ago
  The generated C++ interfaces to gRPC are also filled with an incredible amount of indirection and unnecessary concepts. I'd say it's a "bad at writing complex things simply" culture rather than being Java-specific.
  - hot_gril 2y ago
    Autogenerated code in general tends to be unreadable. It's not easy and/or not a priority.
- jakjak123 2y ago
  Some of the details inside protobuf in Java can be very convoluted, but they are also the result of intense benchmarking, years of experiences and a long tail with deep legacy support for old java. Honestly I found the Java bindings to be way better designed and thought out than Golang. On a consumer level, the immutable message builders are fantastic, the one-ofs are decent compared to what Java can offer, and the service bindings actually provide a beautiful abstraction with their 0-1-many model. In Golang, if you only have to deal with Unary rpc they are OK I guess, but I really miss the immutable messages.
  - hamandcheese 2y ago
    To be clear, I'm not talking about generated code or anything touching protobuf serde. Just grpc-the-library. Interceptors, retry policies, channels, etc.
jeffbee 2y ago
"Adds a build step" is just not a thing you notice in any way if you also use Bazel, which I imagine Google imagines everyone doing. I don't really agree with any of the complaints in this article since they are sort of vague and apparently from the point of view of browsers, whereas I am a backend developer, but I think there is a large universe of things to complain about with gRPC. First and foremost, it seems as though bazel, protobuf C++, and gRPC C++ developers have never spoken to each other and are apparently not aware that it is almost impossible to build and link a gRPC C++ server with bazel. The bazel people have made it impossible to build protobuf with bazel 7 and the protobuf people have made it impossble to use bazel with protobuf 27, while the gRPC people and the rules_proto people are not even in the conversation. The other complaint from the C++ side is that the implementation is now so slow that Go and Java beat it easily, making C++ people look stupid at work.
- rstat1 2y ago
  The last time I attempted to use GRPC++ it was pretty hard to build even without the heaping monstrosity that is Bazel.
athorax 2y ago
I do generally agree the tooling sucks, but as mentioned, buf and the connectrpc ecosystem have made it much easier to get things going.
jayd16 2y ago
Its pretty ironic but Microsoft decided to lean into gRPC support for C#/ASP.NET and its honestly really well done and has great devx.
- PaulWaldman 2y ago
  Why is this ironic?
  - jiveturkey 2y ago
    Google ate their lunch with Chrome, so long ago.
    - eddythompson80 2y ago
      What does that have to do with grpc support in C#?
  - jayd16 2y ago
    I just meant that one of the better implementations is in a language Google doesn't heavily use. Maybe it's not ironic and just a refreshing example of OSS at work.
  - deleted 2y ago
    [deleted]
austin-cheney 2y ago
Yes, all of it. Google claims gRPC with protobuf yields a 10-11x performance improvement over HTTP. I am skeptical of those numbers because really it comes down to the frequency of data parsing into and out of the protobuf format. At any rate just use JSON with WebSockets. Its stupid simple and still 7-8x faster than HTTP with far less administrative overhead than either HTTP or gRPC.
- nevir 2y ago
  > because really it comes down to the frequency of data parsing into and out of the protobuf format. Protobuf is intentionally designed to NOT require any parsing at all. Data is serialized over the wire (or stored on disk) in the same format/byte order that it is stored in memory (Yes, that also means that it's not validated at runtime) Or are you referencing the code we all invariably write before/after protobuf to translate into a more useful format?
  - sa46 2y ago
    You’re likely thinking of Cap’n’Proto or flatbuffers. Protobuf definitely requires parsing. Zero values can be omitted on the wire so there’s not a fixed layout, meaning you can’t seek to a field. In order to find a fields value, you must traverse the entire message, and decode each tag number since the last tag wins.
  - thinkharderdev 2y ago
    > Protobuf is intentionally designed to NOT require any parsing at all This is not true at all. If you have a language-specific class codegen'd by protoc then the in-memory representation of that object is absolutely not the same as the serialized representation. For example: 1. Integer values are varint encoded in the wire format but obviously not in the in-memory format 2. This depends on the language of course but variable length fields are stored inline in the wire format (and length-prefixed) while the in-memory representation will typically use some heap-allocated type (so the in-memory representation has a pointer in that field instead of the data stored inline)
  - arp242 2y ago
neonsunset 2y ago
A lot of tooling badness comes out of the fact that gRPC integration in its lingua franca, Go, requires manual wiring of protoc. I don't know why or how there isn't a one-liner option there, because my experience with using gRPC in C# has been vastly better: dotnet add package Grpc.Tools // note below <Protobuf Include="my_contracs.proto" /> and you have the client and server boilerplate (client - give it url and it's ready for use, server - inherit from base class and implement call handlers as appropriate) - it is all handled behind the scenes by protoc integration that plugs into msbuild, and the end user rarely has to deal with its internals directly unless someone abused definitions in .proto to work as a weird DSL for end to end testing environment and got carried away with namespacing too much (which makes protoc plugins die for most languages so it's not that common of occurrence). The package readme is easy to follow too: https://github.com/grpc/grpc/blob/master/src/csharp/BUILD-INTEGRATION.md https://github.com/grpc/grpc/blob/master/src/csharp/BUILD-IN... Note: usually you need Grpc.Client and Google.Protobuf too but that's two `dotnet add package`s away.
- tracker1 2y ago
  Similar experiences with web services via WCF. It was in dealing with anything published that wasn't .Net where it got difficult. PHP services were not complaint with their own WSDL, similar for internal types in Java from some systems. It was often a mess compared to the C# experience, hence everyone moving towards REST or simpler documentation that was easy to one-off as needed, or use an API client.
  - deleted 2y ago
    [deleted]
- atombender 2y ago
  The Go tooling for gRPC is inexplicably bad, both in terms of ergonomics and in terms of performance. The GoGoProtobuf [1] project was started to improve both. It would generate nice Go types that followed Go's conventions. And it uses fast binary serialization without needing to resort to reflection. Unfortunately, the gRPC/Protobuf team(s) at Google is famously resistant to changes, and was unwilling to work with the GoGo. As a result, the GoGo project is now dead. [2] I've never used Buf, but it looks like it might fix most of the issues with the Go support. [1] https://github.com/gogo/protobuf https://github.com/gogo/protobuf [2] https://x.com/awalterschulze/status/1584553056100057088 https://x.com/awalterschulze/status/1584553056100057088
mdhb 2y ago
I think there is a really nice opportunity to take some emerging open source standards such as CBOR for the wire format, CDDL for the schema definition and code generation inputs and WebTransport for the actual transport layer.
devmunchies 2y ago
My biggest issue with GRPC is direct mapping of ip addresses in the config or at runtime. From the docs: "When sending a gRPC request, the client must determine the IP address of the service name." https://grpc.io/docs/guides/custom-name-resolution/ https://grpc.io/docs/guides/custom-name-resolution/ My preferred approach would be to map my client to a "topic" and then any number of servers can subscribe to the topic. Completely decoupled, scaling up is much easier. My second biggest issue is proto file versioning. I'm using NATS for cross-service comms and its great. just wish it had a low-level serialization mechanism for more efficient transfer like grpc.
- dilyevsky 2y ago
  There’s https://github.com/nats-rpc/nrpc https://github.com/nats-rpc/nrpc
skywhopper 2y ago
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 API rigidity far sooner than is healthy. One project I worked on was basically just a system for sharing a JSON document to multiple other systems. This was at a golang shop on AWS. We could have used an S3 bucket. But sure, an API might be nice so you can add a custom auth layer or add server side filters and queries down the road. So we built a REST API in a couple of weeks. But then the tech lead felt bad that we hadn’t used gRPC like the cool kids on other teams. What if we needed a Python client so we could build a Ansible plugin to call the API?? (I mean, Ansible plugins can be in any language; it’s a rest API, Ansible already supports calling that (or you could just use curl); or you could write the necessary Python to call the REST API in like three lines of code.) so we spent months converting to gRPC, except we needed to use the Connect library because it’s cooler, except it turns out it doesn’t support GET calls, and no one else at the company was using it. By the time we built the entire service, we had spent months, it was impossible to troubleshoot, just calling the API for testing required all sorts of harnesses and mocks, no good CLI tooling, and we were generating a huge Python library to support the Ansible use case, but it turned out that wasn’t going to work for other reasons. Eventually everyone on that team left the company or moved to other projects. I don’t think anything came of it all but we probably cost the company a million dollars. Go gRPC!
- thinkharderdev 2y ago
  > 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 API rigidity far sooner than is healthy. This sounds odd to me because I don't really see how gRPC would cause any of those issues? > layers of gRPC trash What layers? Switching from REST (presumably JSON over http) to gRPC shouldn't introduce any new "layers". It's replacing one style of API call with a different one. > learning multiple new tools and DSLs 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? > ultimately tends to force API rigidity far sooner than is healthy How does gRPC force API rigidity? It is specifically designed to be evolvable (sometimes to its usability detriment IMO) There are some definite footguns with gRPC and I am becoming increasingly annoyed with Protobuf in particular as the years go on, but going back to REST APIs still seems like a huge step backwards to me. With gRPC you get a workflow that starts with a well-defined interface and all the language bindings client/server stubs are generated from that with almost zero effort. You can kind of/sort of do that with REST APIs using openapi specs but in my experience it just doesn't work that well and language support is sorely lacking.
_zoltan_ 2y ago
in my latest project I actually needed an rpc library that was hardware accelerated and I was surprised gRPC doesn't do RDMA for example. why is that?
lalaithion 2y ago
We use the textproto format extensively at work; it's super nice to be able to define tests of your APIs by using .textpb inputs and golden .textpb outputs. We have so many more tests using this method than if we manually called the APIs by in a programming language for each test case, and I wouldn't want to use JSON for test inputs, since it lacks comments.
- jvolkman 2y ago
  If you use intellij, you can annotate your text protos with some header comments and unlock schema validation, completion, etc.
- sudorandom 2y ago
  Author here: Sorry that I was so harsh on textproto. You are right that it has some strengths over JSON... I'm actually a fan of JSONC for this reason. It does limit you on tooling... but so does textproto, right? I think the bigger thing that I'm worried about is that gRPC has so many mandatory features that it can become hard to make a good implementation in new languages. To be honest there are some languages where the gRPC implementation is just not great and I blame the feature bloat... and I think textproto was a good demonstration of that feature bloat to me.
  - jakjak123 2y ago
    Yeah, the feature bloat makes it a hurdle to make some good quality implementations. I mostly stayed in Java for years. They are quite good. grpc-web is ok I guess, protobuf-ts are great, swift came along as nice, then I have always been saddened by how awful they are in Go. You will get terrible enums, terrible one-ofs, the interceptors and service registration are very awkward.
slavomirvojacek 2y ago
I am surprised no-one is mentioning Buf for all the great work they've done with the CLI and Connect for much better devex, tooling, and interoperability.
stairlane 2y ago
Something I didn’t see listed was the lack of a package manager for protos. For example if I want to import some common set of structs into my protos, there isn’t a standardized or wide spread way to do this. Historically I have had to resort to either copying the structs over or importing multiple protoc generated modules in my code (not in my protos). If there was a ‘go get’ or ‘pip install’ equivalent for protos, that would be immensely useful; for me and my colleagues at least.
- JeffMcCune 2y ago
  https://buf.build/ https://buf.build/ is this, no?
  - stairlane 2y ago
    Thanks for sharing! Yes things like this would help solve our problems.
- ergl 2y ago
  It is mentioned under the "Bad tooling" section
  - stairlane 2y ago
    Oh my mistake, must have missed that.
cletus 2y ago
Story time: the whole development of protobuf was... a mess. It was developed and used internally at Google long before it was ever open sourced. Protobuf was designed first and foremost for C++. This makes sense. All of Google's core services are in C++. Yes there's Java (and now Go and to some extent Python). I know. But protobuf was and is a C++-first framework. It's why you have features like arena allocation [1]. Internally there was protobuf v1. I don't know a lot about this because it was mostly gone by the time I started at Google. protobuf v2 was (and, I imagine, still is) the dominant form of. Now, this isn't to be confused with the API version, which is a completely different thing. You would specify this in BUILD files and it was a complete nightmare because it largely wasn't interchangeable. The big difference is with java_api_version = 1 or 2. Java API v1 was built like the java.util.Date class. Mutable objects with setters and getters. v2 changed this to the builder pattern. At the time (this may have changed) you couldn't build the artifacts for both API versions and you'd often want to reuse key protobuf definitions that other people owned so you ended up having to use v1 API because some deep protobuf hadn't been migrated (and probably never would be). It got worse because sometimes you'd have one dependency on v1 and another on v2 so you ended up just using bytes fields because that's all you could do. This part was a total mess. What you know as gRPC was really protobuf v3 and it was designed largely for Cloud (IIRC). It's been some years so again, this may have changed, but there was never any intent to migrate protobuf v2 to v3. There was no clear path to do that. So any protobuf v3 usage in Google was really just for external use. I explain this because gRPC fails the dogfood test. It's lacking things because Google internally doesn't use it. So why was this done? I don't know the specifics but I believe it came down to licensing. While protobuf v2 was open sourced the RPC component (internally called "Stubby") never was. I believe it was a licensing issue with some dependency but it's been awhile and honestly I never looked into the specifics. I just remember hearing that it couldn't be done. So when you read about things like poor JSON support (per this article), it starts to make sense. Google doesn't internally use JSON as a transport format. Protobuf is, first and foremost, a wire format for C++-cetnric APIs (in Stubby). Yes, it was used in storage too (eg Bigtable). Protobuf in Javascriipt was a particularly horrendous Frankenstein. Obviously Javascript doesn't support binary formats like protobuf. You have to use JSON. And the JSON bridges to protobuf were all uniquely awful for different reasons. My "favorite" was pblite, which used a JSON array indexed by the protobuf tag number. With large protobufs with a lot of optional fields you ended up with messages like: [null,null,null,null,...(700 more nulls)...,null,{/*my message*/}] GWT (for Java) couldn't compile Java API protobufs for various reasons so had to use a variant as well. It was just a mess. All for "consistency" of using the same message format everywhere. [1]: https://protobuf.dev/reference/cpp/arenas/ https://protobuf.dev/reference/cpp/arenas/
ainar-g 2y ago
Re. bad tooling. grpcurl[1] is irreplaceable when working with gRPC APIs. It allows you to make requests even if you don't have the .proto around. [1]: https://github.com/fullstorydev/grpcurl https://github.com/fullstorydev/grpcurl
- CommonGuy 2y ago
  One can use Kreya for a GUI version
- abdusco 2y ago
  > make requests even if you don't have the .proto around Like this? > grpcurl -d '{"id": 1234, "tags": ["foo","bar"]}' \ grpc.server.com:443 my.custom.server.Service/Method How is that even possible? How could grpcurl know how to translate your request to binary?
  - ainar-g 2y ago
    If I recall correctly, ProtoBuf has a reflection layer, and it's probably using that.
  - BobbyJo 2y ago
    I could be wrong, but it is probably using json encoding for the object body, and implementing the transport for grpc instead of http. Proto objects support json encode/decode by default in all the implementations I've seen. https://grpc.io/blog/grpc-with-json/ https://grpc.io/blog/grpc-with-json/
- jakjak123 2y ago
  I just build a cli in Java or Go. It literally takes minutes to build a client.
mattboardman 2y ago
My biggest complaint with gRPC is proto3 making all nested type fields optional while making primitives always present with default values. gRPC is contract based so it makes no sense to me that you can't require a field. This is especially painful from an ergonomics viewpoint. You have to null check every field with a non primitive type.
- dudus 2y ago
  If I remember correctly the initial version allowed required fields but it caused all sorts of problems when trying to migrate protos because a new required fields breaks all consumers almost by definition. So updating protos in isolation becomes tricky. The problem went away with all optional fields so it was decided the headache wasn't worth it.
  - bunderbunder 2y ago
    I used to work at a company that used proto2 as part of a homegrown RPC system that predated gRPC. Our coding standards strongly discouraged making anything but key fields required, for exactly this reason. They were just too much of a maintenance burden in the long run. I suspect that not having nullable fields, though, is just a case of letting an implementation detail, keeping the message representation compatible with C structs in the core implementation, bleed into the high-level interface. That design decision is just dripping with "C++ programmers getting twitchy about performance concerns" vibes.
    - fyrn_ 2y ago
      Zoox?
  - fisian 2y ago
    That decision seems practical (especially at Google scale). I think the main problem with it, is that you cannot distinguish if the field has the default value or just wasn't set (which is just error prone). However, there are solutions to this, that add very little overhead to the code and to message size (see e.g. [1]). [1]: https://protobuf.dev/programming-guides/dos-donts/ https://protobuf.dev/programming-guides/dos-donts/
cryptonector 2y ago
> Bad tooling Lolwut. This is what was always said about ASN.1 and the reason that this wheel has to be reinvented periodically.
- throwaway894345 2y ago
  It can be true for both ASN.1 and gRPC? Moreover, definitions of "bad" can vary.
  - cryptonector 2y ago
    Before inventing a new serialization protocol it would be good to first study the field and pick an existing protocol that ticks all the right boxes, and if the tooling isn't very good then write new tooling -- you'd have to write new tooling for a new protocol anyways, but if you can find a good enough existing one then you don't also have to write a spec, thus saving you a lot of time.
bunderbunder 2y ago
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.
- neonsunset 2y ago
  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.
  - pixl97 2y ago
    >It is possible to do quite well, as demonstrated by {one of the other largest companies in the world} FTFY
  - svaha1728 2y ago
    No disrespect to the other developers on the team, but James Newton-King is no ordinary developer.
  - kodablah 2y ago
    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 https://github.com/grpc/grpc-dotnet/issues/303
epgui 2y ago
A lot of this kind of criticism rubs me the wrong way, especially complaining about having to use words or maths concepts, or having to learn new things. That's often not really a statement on the inherent virtue of a tool, and more of a statement on the familiarity of the author. I don't want to sound flippant, but if you don't want to learn new things, don't use new tools :D
- usrnm 2y ago
  Sending a request and getting a response back is not a new concept, it's about as old as computer networks in general, and gRPC is the only framework that refers to this concept as "unary". This is the original argument from the article and I tend to agree with it
  - epgui 2y ago
    Monads and functors are nothing new either, but that doesn’t mean giving them that name was a bad idea. Moreover, the term “unary” is used to distinguish from other, non-unary options: https://grpc.io/docs/what-is-grpc/core-concepts/ https://grpc.io/docs/what-is-grpc/core-concepts/
- throwaway894345 2y ago
  > I don't want to sound flippant, but if you don't want to learn new things, don't use new tools :D That's precisely the problem. The author wants to convince people (e.g., his colleagues) to use a new tool, but he has to convince them to learn a bunch of new things including a bunch of new things that aren't even necessary.
jscheel 2y ago
The tooling around gRPC with bazel when using python is so bad it’s almost impossible to work with, which is hilarious considering they both come from Google. Then I had additional problems getting it to work with Ruby. Then I had more problems getting it to work in k8s, because of load balancing with http/2. Combine those issues with a number of other problems I ran into with gRPC, and I ended up just building a small JSON-RPC implementation that fit our needs perfectly.
- doctorpangloss 2y ago
  Another point of view is, don't use Bazel. In my experience, Gradle is less of a headache and well supported.
  - jscheel 2y ago
    For python? Gradle doesn't really support python.
    - kaba0 2y ago
      I mean, gradle is a generic build tool. It could support it, just as it can be used to compile C (I have done the latter).
  - metadat 2y ago
    Gradle is an anti-pattern. Just stick with Maven and live a happy life. As someone who's used Gradle tons, 6 months ago I wrote in detail about why not gradle: https://news.ycombinator.com/item?id=38875936 https://news.ycombinator.com/item?id=38875936 Gradle still might less bad than Bazel, though.
    - EdwardDiego 2y ago
      I'm firmly in the Maven is better than Gradle camp. Yes, it's less flexible, that's why I like it. Gradle might be better if it wasn't a poorly documented Groovy/Kotlin DSL where everything is a closure, but I do like the fact that if you want to do something in Maven you need a plugin that couples to known points in the lifecycle. It makes it explicit what is doing what and where. And fully agree on the incredible pain of Gradle upgrades.
cyberax 2y ago
I'm surprised the author doesn't mention ConnectRPC: https://connectrpc.com/ https://connectrpc.com/ It solves ALL the problems of vanilla gRPC, and it even is compatible with the gRPC clients! It grew out of Twirp protocol, which I liked so much I made a C++ implementation: https://github.com/Cyberax/twirp-cpp https://github.com/Cyberax/twirp-cpp But ConnectRPC guys went further, and they built a complete infrastructure for RPC. Including a package manager (buf.build), integration with observability ( https://connectrpc.com/docs/go/observability/ https://connectrpc.com/docs/go/observability/ ). And most importantly, they also provide a library to do rich validation (mandatory fields, field limits, formats, etc): https://buf.build/bufbuild/protovalidate https://buf.build/bufbuild/protovalidate Oh, and for the unlimited message problem, you really need to use streaming. gRPC supports it, as does ConnectRPC.
- athorax 2y ago
  The author does mention it in the article and is also a contributor to supporting tooling https://github.com/sudorandom/protoc-gen-connect-openapi https://github.com/sudorandom/protoc-gen-connect-openapi
- sudorandom 2y ago
  Author here: I definitely should have been more explicit for my love of connectrpc, buf, protovalidate, etc. I do mention ConnectRPC but maybe not as loud as I could have. I definitely try to avoid confessing my love for ConnectRPC in every post, but sometimes it's hard not to because they've made such good strategic decisions that just make sense and round out the ecosystem so well.
  - cyberax 2y ago
    My fault, I did read the article but I overlooked the ConnectRPC mention.
hot_gril 2y ago
I don't understand why there isn't an HTTP/1 mode for gRPC. Would cover the super common use case of client-to-server calls. Give people who already have your typical JSON-over-HTTP API something that's the same except more efficient and with a nicer API spec. You know what's ironic, Google AppEngine doesn't support HTTP/2. Actually a lot of platforms don't.
- bunderbunder 2y ago
  The streaming message transfer modes are the main thing that make it difficult.
  - hot_gril 2y ago
    Streaming seems like it'd work without too much effort. It'd be less efficient for sure, but it's also not a very common use case.
    - bunderbunder 2y ago
      In general, I agree. But my understanding is that the problem isn't streaming in the abstract, it's supporting certain details of the streaming protocol outlined in the gRPC spec.
pcj-github 2y ago
FWIW I never worked at Google and I used protobuf / gRPC extensively at work and in nearly all of my side projects. Personally, I think overall it's great. I do wish trailers were an optional feature though.
kookamamie 2y ago
Insisting a particularly exotic flavor of HTTP(2) is its most severe design flaw, I think. Especially, as it could have worked in an agnostic manner, e.g. on top WebSockets.
- sudorandom 2y ago
  Author here: it's nerdy web trivia but HTTP trailers are actually in the HTTP/1.1 spec, although very few browsers, load balancers, programming languages, etc. implemented it at the time since it wasn't super useful for the web. You are definitely correct that it is an exotic feature that often gets forgotten about.
FridgeSeal 2y ago
> Why does gRPC have to use such a non-standard term for this that only mathematicians have an intuitive understanding of? I have to explain the term every time I use it. Who are you working with lol? Nobody I’ve worked with has struggled with this concept, and I’ve worked with a range of devs, including very junior and non-native-English speakers. > Also, it doesn’t pass my “send a friend a cURL example” test for any web API. Well yeah. It’s not really intended for that use-case? > The reliance on HTTP/2 initially limited gRPC’s reach, as not all platforms and browsers fully supported it Again, not the intended use-case. Where does this web-browsers-are-the-be-all-and-of-tech attitude come from? Not everything needs to be based around browser support. I do agree on http/3 support lacking though. > lack of a standardized JSON mapping Because JSON has an extremely anaemic set of types that either fail to encode the same semantics, or require all sorts of extra verbosity to encode. I have the opposite experience with protobuf: I know the schema, so I know what I expect to get valid data, I don’t need to rely on “look at the json to see if I got the field capitalisation right”. > It has made gRPC less accessible for developers accustomed to JSON-based APIs Because god forbid they ever had to learn anything new right? Nope, better for the rest of us to just constantly bend over backwards to support the darlings who “only know json” and apparently can’t learn anything else, ever. > Only google would think not solving dependency management is the solution to dependency management Extremely good point. Will definitely be looking at Buf the next time I touch GRPC things. GRPC is a lower-overhead, binary rpc for server-to-server or client-server use cases that want better performance and faster integration that a shared schema/IDL permits. Being able to drop in some proto files and automatically have a package with the methods available and not having to spend time wiring up url’s and writing types and parsing logic is amazing. Sorry it’s not a good fit for serving your webpage, criticising it for not being good at web stuff is like blaming a tank for not winning street races. GRPC isn’t without its issues and shortcomings- I’d like to see better enums and a stronger type system, and defs http/3 or raw quic transport.
- lanstin 2y ago
  I use protobuf to specify my protocol and then generate a swagger/openAPI spec then use some swagger codegen to generate rest client libraries. For a proxy server I have to fill in some stub methods to parse the json and turn it into a gRPC call but for the gRPC server there is some library that generates a rest service listener that just calls into the gRPC server code. It works fine. I had to annotate the proto file to say what REST path to use.
tgma 2y ago
gRPC is deliberately designed not to be dependent on protobuf for its message format. It can be used to transfer other serialization formats. However, the canonical stub generator, which is not hard to replace at all, assumes proto so when people hear gRPC they really think of Protobuf over gRPC. Most of the complaints should be directed at protobuf, with or without gRPC. The primary misfeature of gRPC itself, irrespective of protobuf, is relying on trailers for status code, which hindered its adoption in the context of web browser without an edge proxy that could translate gRPC and gRPC-web wire formats. That alone IMO hindered the universal applicability and adoption quite a bit.
- bootloop 2y ago
  Do you know of an example where this is done? I didn't know that and we are currently using a customized wire format (based on a patched Thrift), so I thought gRPC wouldn't be an option for us.
  - tgma 2y ago
    I have done it in proprietary settings. Nothing off the top of my head. The gRPC libraries themselves are pretty straightforward. You just need to use thrift IDL parser to output stubs that use gRPC under the hood. The C++ one may be slightly more challenging to replace because extra care is needed to make sure protobuf message pipeline is zero-copy. Other languages are more trivial. One place to start would be to look at the gRPC protoc plugin and see how it’s outputting code and do something similar. Pretty lean code.
- jakjak123 2y ago
  This is the true design issue with gRPC as I see it. It would be way bigger without this. I love protobuf though, gRPC is just alright. At least gRPC makes it so much simpler to build powerful automation and tooling around it than the wild west of randomly created 'json'-ish REST-ish APIs.
cherryteastain 2y ago
For me, the breaking point was when I saw the C++ bindings unironically recommend [1] that you use terrible anti-patterns such as "delete this". I find it unlikely that all these incredibly well paid Google engineers are unaware how people avoid these anti-patterns in idiomatic C++ (by e.g. std::shared_ptr). The only remaining sensible explanation is that Google internal gRPC C++ tooling must have utilities that abstract away this ugly underbelly, which us mere mortals are not privy to. [1] https://grpc.io/docs/languages/cpp/callback/ https://grpc.io/docs/languages/cpp/callback/
deleted 2y ago
[deleted]
pjmlp 2y ago
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 doing gRPC are available in Visual Studio.
- pjc50 2y ago
  > 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)
  - pjmlp 2y ago
    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.
camgunz 2y ago
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.
bitzun 2y ago
My main problems with grpc are threefold: - The implementation quality and practices vary a lot. The python library lacks features that the go library has because they are philosophically opposed to them. Protobuf/grpc version pinning between my dependencies has broken repeatedly for me. - If you are a services team, your consumers inherit a lot of difficult dependencies. Any normal json api does not do this, with openapi the team can use codegen or not. - The people who have been most hype to me in person about grpc repeat things like "It's just C structs on the wire" which is completely fucking wrong, or that protobuf is smaller than json which is a more situational benefit. My point being their "opinion" is uninformed and band-wagoning. This article gave me some new options for dunking on grpc if it's recommended.

228 points by temp_praneshp 2y ago

While one can't refute the existence of the mentioned warts, they are not a big concern practically. We use gRPC in our Partner SDK[0] and Connector SDK[1]. [0] https://fivetran.com/docs/partner-built-program https://fivetran.com/docs/partner-built-program [1] https://fivetran.com/docs/connectors/connector-sdk https://fivetran.com/docs/connectors/connector-sdk

tempest_ 2y ago

One of my favourite bits is having to pass a json string to the python library to configure a service. To this day I am not entirely sure it is adhering to the config

ycombinatrix 2y ago
same in java

hamandcheese 2y ago

I remember being surprised at how hard it was to read the source code for grpc Java. There's an incredible amount of indirection at every turn. This made it extremely hard to get answers to questions that were undocumented. It's a shame because I know Google can put out easy to read code (see: the go standard library).

hinkley 2y ago
Sass was the first code generator I ever met that produced decent output. I’d been coding for 15 years at that point. Less is the second one. That’s the end of this story. There are basically two people in the world who have demonstrated that they can be trusted to generate code that isn’t an impenetrable quagmire of pain and confusion. I doubt it’s an accident that both emitted declarative output rather than imperative, but I would be happy to be proven wrong.
ot 2y ago
> It's a shame because I know Google can put out easy to read code (see: the go standard library). My guess is that the difference is that go is managed by a small group of engineers that have strong opinions, really care about it, and they have reached "fuck you level", so they can prioritize what they think is important instead of what would look good on a promo packet.
delusional 2y ago
I think it's partly a culture thing. Java developers love indirection, and they're used to an ecosystem that doesn't want to be understood. An ecosystem that wants you to google whatever obtuse error message it decides to spit out, and paste whatever half thought out annotation some blog post spits back, into your code to make it work. I've worked with people who considered anything that wasn't programmed with annotations to be "too advanced" for their use-case.
- hot_gril 2y ago
  Java is on life support as a language, but the ecosystem is strong, that's why it has all these weird features via annotations. And people who use Java are just trying to get stuff done like everyone else.
  - za3faran 2y ago
    Java is doing quite well.
  - kaba0 2y ago
    How is it on life support, when it’s by far the biggest server-side language, running basically every top companies’ business critical infrastructure? Also, annotations are just metaprogramming, which can be tastefully applied.
    - hot_gril 2y ago
      Like I said, the ecosystem is strong. The language's design hasn't aged well, so nowadays any Java code I see in prod has 1-4 annotations above every class and method to get around the limitations of the language. Similar to how some C code will rely heavily on macros.
      - kaba0 2y ago
        That’s not due to the language, but due to the business domain (I assume web development). In this domain almost every framework, regardless of language, will heavily use metaprogramming, see django, etc.
cjensen 2y ago
The generated C++ interfaces to gRPC are also filled with an incredible amount of indirection and unnecessary concepts. I'd say it's a "bad at writing complex things simply" culture rather than being Java-specific.
- hot_gril 2y ago
  Autogenerated code in general tends to be unreadable. It's not easy and/or not a priority.
jakjak123 2y ago
Some of the details inside protobuf in Java can be very convoluted, but they are also the result of intense benchmarking, years of experiences and a long tail with deep legacy support for old java. Honestly I found the Java bindings to be way better designed and thought out than Golang. On a consumer level, the immutable message builders are fantastic, the one-ofs are decent compared to what Java can offer, and the service bindings actually provide a beautiful abstraction with their 0-1-many model. In Golang, if you only have to deal with Unary rpc they are OK I guess, but I really miss the immutable messages.
- hamandcheese 2y ago
  To be clear, I'm not talking about generated code or anything touching protobuf serde. Just grpc-the-library. Interceptors, retry policies, channels, etc.

jeffbee 2y ago

"Adds a build step" is just not a thing you notice in any way if you also use Bazel, which I imagine Google imagines everyone doing. I don't really agree with any of the complaints in this article since they are sort of vague and apparently from the point of view of browsers, whereas I am a backend developer, but I think there is a large universe of things to complain about with gRPC. First and foremost, it seems as though bazel, protobuf C++, and gRPC C++ developers have never spoken to each other and are apparently not aware that it is almost impossible to build and link a gRPC C++ server with bazel. The bazel people have made it impossible to build protobuf with bazel 7 and the protobuf people have made it impossble to use bazel with protobuf 27, while the gRPC people and the rules_proto people are not even in the conversation. The other complaint from the C++ side is that the implementation is now so slow that Go and Java beat it easily, making C++ people look stupid at work.

rstat1 2y ago
The last time I attempted to use GRPC++ it was pretty hard to build even without the heaping monstrosity that is Bazel.

athorax 2y ago

I do generally agree the tooling sucks, but as mentioned, buf and the connectrpc ecosystem have made it much easier to get things going.

jayd16 2y ago

Its pretty ironic but Microsoft decided to lean into gRPC support for C#/ASP.NET and its honestly really well done and has great devx.

PaulWaldman 2y ago
Why is this ironic?
- jiveturkey 2y ago
  Google ate their lunch with Chrome, so long ago.
  - eddythompson80 2y ago
    What does that have to do with grpc support in C#?
- jayd16 2y ago
  I just meant that one of the better implementations is in a language Google doesn't heavily use. Maybe it's not ironic and just a refreshing example of OSS at work.
- deleted 2y ago
  [deleted]

austin-cheney 2y ago

Yes, all of it. Google claims gRPC with protobuf yields a 10-11x performance improvement over HTTP. I am skeptical of those numbers because really it comes down to the frequency of data parsing into and out of the protobuf format. At any rate just use JSON with WebSockets. Its stupid simple and still 7-8x faster than HTTP with far less administrative overhead than either HTTP or gRPC.

nevir 2y ago
> because really it comes down to the frequency of data parsing into and out of the protobuf format. Protobuf is intentionally designed to NOT require any parsing at all. Data is serialized over the wire (or stored on disk) in the same format/byte order that it is stored in memory (Yes, that also means that it's not validated at runtime) Or are you referencing the code we all invariably write before/after protobuf to translate into a more useful format?
- sa46 2y ago
  You’re likely thinking of Cap’n’Proto or flatbuffers. Protobuf definitely requires parsing. Zero values can be omitted on the wire so there’s not a fixed layout, meaning you can’t seek to a field. In order to find a fields value, you must traverse the entire message, and decode each tag number since the last tag wins.
- thinkharderdev 2y ago
  > Protobuf is intentionally designed to NOT require any parsing at all This is not true at all. If you have a language-specific class codegen'd by protoc then the in-memory representation of that object is absolutely not the same as the serialized representation. For example: 1. Integer values are varint encoded in the wire format but obviously not in the in-memory format 2. This depends on the language of course but variable length fields are stored inline in the wire format (and length-prefixed) while the in-memory representation will typically use some heap-allocated type (so the in-memory representation has a pointer in that field instead of the data stored inline)
- arp242 2y ago

neonsunset 2y ago

A lot of tooling badness comes out of the fact that gRPC integration in its lingua franca, Go, requires manual wiring of protoc. I don't know why or how there isn't a one-liner option there, because my experience with using gRPC in C# has been vastly better: dotnet add package Grpc.Tools // note below <Protobuf Include="my_contracs.proto" /> and you have the client and server boilerplate (client - give it url and it's ready for use, server - inherit from base class and implement call handlers as appropriate) - it is all handled behind the scenes by protoc integration that plugs into msbuild, and the end user rarely has to deal with its internals directly unless someone abused definitions in .proto to work as a weird DSL for end to end testing environment and got carried away with namespacing too much (which makes protoc plugins die for most languages so it's not that common of occurrence). The package readme is easy to follow too: https://github.com/grpc/grpc/blob/master/src/csharp/BUILD-INTEGRATION.md https://github.com/grpc/grpc/blob/master/src/csharp/BUILD-IN... Note: usually you need Grpc.Client and Google.Protobuf too but that's two `dotnet add package`s away.

tracker1 2y ago
Similar experiences with web services via WCF. It was in dealing with anything published that wasn't .Net where it got difficult. PHP services were not complaint with their own WSDL, similar for internal types in Java from some systems. It was often a mess compared to the C# experience, hence everyone moving towards REST or simpler documentation that was easy to one-off as needed, or use an API client.
- deleted 2y ago
  [deleted]
atombender 2y ago
The Go tooling for gRPC is inexplicably bad, both in terms of ergonomics and in terms of performance. The GoGoProtobuf [1] project was started to improve both. It would generate nice Go types that followed Go's conventions. And it uses fast binary serialization without needing to resort to reflection. Unfortunately, the gRPC/Protobuf team(s) at Google is famously resistant to changes, and was unwilling to work with the GoGo. As a result, the GoGo project is now dead. [2] I've never used Buf, but it looks like it might fix most of the issues with the Go support. [1] https://github.com/gogo/protobuf https://github.com/gogo/protobuf [2] https://x.com/awalterschulze/status/1584553056100057088 https://x.com/awalterschulze/status/1584553056100057088

mdhb 2y ago

I think there is a really nice opportunity to take some emerging open source standards such as CBOR for the wire format, CDDL for the schema definition and code generation inputs and WebTransport for the actual transport layer.

devmunchies 2y ago

My biggest issue with GRPC is direct mapping of ip addresses in the config or at runtime. From the docs: "When sending a gRPC request, the client must determine the IP address of the service name." https://grpc.io/docs/guides/custom-name-resolution/ https://grpc.io/docs/guides/custom-name-resolution/ My preferred approach would be to map my client to a "topic" and then any number of servers can subscribe to the topic. Completely decoupled, scaling up is much easier. My second biggest issue is proto file versioning. I'm using NATS for cross-service comms and its great. just wish it had a low-level serialization mechanism for more efficient transfer like grpc.

dilyevsky 2y ago
There’s https://github.com/nats-rpc/nrpc https://github.com/nats-rpc/nrpc

skywhopper 2y ago

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 API rigidity far sooner than is healthy. One project I worked on was basically just a system for sharing a JSON document to multiple other systems. This was at a golang shop on AWS. We could have used an S3 bucket. But sure, an API might be nice so you can add a custom auth layer or add server side filters and queries down the road. So we built a REST API in a couple of weeks. But then the tech lead felt bad that we hadn’t used gRPC like the cool kids on other teams. What if we needed a Python client so we could build a Ansible plugin to call the API?? (I mean, Ansible plugins can be in any language; it’s a rest API, Ansible already supports calling that (or you could just use curl); or you could write the necessary Python to call the REST API in like three lines of code.) so we spent months converting to gRPC, except we needed to use the Connect library because it’s cooler, except it turns out it doesn’t support GET calls, and no one else at the company was using it. By the time we built the entire service, we had spent months, it was impossible to troubleshoot, just calling the API for testing required all sorts of harnesses and mocks, no good CLI tooling, and we were generating a huge Python library to support the Ansible use case, but it turned out that wasn’t going to work for other reasons. Eventually everyone on that team left the company or moved to other projects. I don’t think anything came of it all but we probably cost the company a million dollars. Go gRPC!

thinkharderdev 2y ago
> 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 API rigidity far sooner than is healthy. This sounds odd to me because I don't really see how gRPC would cause any of those issues? > layers of gRPC trash What layers? Switching from REST (presumably JSON over http) to gRPC shouldn't introduce any new "layers". It's replacing one style of API call with a different one. > learning multiple new tools and DSLs 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? > ultimately tends to force API rigidity far sooner than is healthy How does gRPC force API rigidity? It is specifically designed to be evolvable (sometimes to its usability detriment IMO) There are some definite footguns with gRPC and I am becoming increasingly annoyed with Protobuf in particular as the years go on, but going back to REST APIs still seems like a huge step backwards to me. With gRPC you get a workflow that starts with a well-defined interface and all the language bindings client/server stubs are generated from that with almost zero effort. You can kind of/sort of do that with REST APIs using openapi specs but in my experience it just doesn't work that well and language support is sorely lacking.

_zoltan_ 2y ago

in my latest project I actually needed an rpc library that was hardware accelerated and I was surprised gRPC doesn't do RDMA for example. why is that?

lalaithion 2y ago

We use the textproto format extensively at work; it's super nice to be able to define tests of your APIs by using .textpb inputs and golden .textpb outputs. We have so many more tests using this method than if we manually called the APIs by in a programming language for each test case, and I wouldn't want to use JSON for test inputs, since it lacks comments.

jvolkman 2y ago
If you use intellij, you can annotate your text protos with some header comments and unlock schema validation, completion, etc.
sudorandom 2y ago
Author here: Sorry that I was so harsh on textproto. You are right that it has some strengths over JSON... I'm actually a fan of JSONC for this reason. It does limit you on tooling... but so does textproto, right? I think the bigger thing that I'm worried about is that gRPC has so many mandatory features that it can become hard to make a good implementation in new languages. To be honest there are some languages where the gRPC implementation is just not great and I blame the feature bloat... and I think textproto was a good demonstration of that feature bloat to me.
- jakjak123 2y ago
  Yeah, the feature bloat makes it a hurdle to make some good quality implementations. I mostly stayed in Java for years. They are quite good. grpc-web is ok I guess, protobuf-ts are great, swift came along as nice, then I have always been saddened by how awful they are in Go. You will get terrible enums, terrible one-ofs, the interceptors and service registration are very awkward.

slavomirvojacek 2y ago

I am surprised no-one is mentioning Buf for all the great work they've done with the CLI and Connect for much better devex, tooling, and interoperability.

stairlane 2y ago

Something I didn’t see listed was the lack of a package manager for protos. For example if I want to import some common set of structs into my protos, there isn’t a standardized or wide spread way to do this. Historically I have had to resort to either copying the structs over or importing multiple protoc generated modules in my code (not in my protos). If there was a ‘go get’ or ‘pip install’ equivalent for protos, that would be immensely useful; for me and my colleagues at least.

JeffMcCune 2y ago
https://buf.build/ https://buf.build/ is this, no?
- stairlane 2y ago
  Thanks for sharing! Yes things like this would help solve our problems.
ergl 2y ago
It is mentioned under the "Bad tooling" section
- stairlane 2y ago
  Oh my mistake, must have missed that.

cletus 2y ago

Story time: the whole development of protobuf was... a mess. It was developed and used internally at Google long before it was ever open sourced. Protobuf was designed first and foremost for C++. This makes sense. All of Google's core services are in C++. Yes there's Java (and now Go and to some extent Python). I know. But protobuf was and is a C++-first framework. It's why you have features like arena allocation [1]. Internally there was protobuf v1. I don't know a lot about this because it was mostly gone by the time I started at Google. protobuf v2 was (and, I imagine, still is) the dominant form of. Now, this isn't to be confused with the API version, which is a completely different thing. You would specify this in BUILD files and it was a complete nightmare because it largely wasn't interchangeable. The big difference is with java_api_version = 1 or 2. Java API v1 was built like the java.util.Date class. Mutable objects with setters and getters. v2 changed this to the builder pattern. At the time (this may have changed) you couldn't build the artifacts for both API versions and you'd often want to reuse key protobuf definitions that other people owned so you ended up having to use v1 API because some deep protobuf hadn't been migrated (and probably never would be). It got worse because sometimes you'd have one dependency on v1 and another on v2 so you ended up just using bytes fields because that's all you could do. This part was a total mess. What you know as gRPC was really protobuf v3 and it was designed largely for Cloud (IIRC). It's been some years so again, this may have changed, but there was never any intent to migrate protobuf v2 to v3. There was no clear path to do that. So any protobuf v3 usage in Google was really just for external use. I explain this because gRPC fails the dogfood test. It's lacking things because Google internally doesn't use it. So why was this done? I don't know the specifics but I believe it came down to licensing. While protobuf v2 was open sourced the RPC component (internally called "Stubby") never was. I believe it was a licensing issue with some dependency but it's been awhile and honestly I never looked into the specifics. I just remember hearing that it couldn't be done. So when you read about things like poor JSON support (per this article), it starts to make sense. Google doesn't internally use JSON as a transport format. Protobuf is, first and foremost, a wire format for C++-cetnric APIs (in Stubby). Yes, it was used in storage too (eg Bigtable). Protobuf in Javascriipt was a particularly horrendous Frankenstein. Obviously Javascript doesn't support binary formats like protobuf. You have to use JSON. And the JSON bridges to protobuf were all uniquely awful for different reasons. My "favorite" was pblite, which used a JSON array indexed by the protobuf tag number. With large protobufs with a lot of optional fields you ended up with messages like: [null,null,null,null,...(700 more nulls)...,null,{/*my message*/}] GWT (for Java) couldn't compile Java API protobufs for various reasons so had to use a variant as well. It was just a mess. All for "consistency" of using the same message format everywhere. [1]: https://protobuf.dev/reference/cpp/arenas/ https://protobuf.dev/reference/cpp/arenas/

ainar-g 2y ago

Re. bad tooling. grpcurl[1] is irreplaceable when working with gRPC APIs. It allows you to make requests even if you don't have the .proto around. [1]: https://github.com/fullstorydev/grpcurl https://github.com/fullstorydev/grpcurl

CommonGuy 2y ago
One can use Kreya for a GUI version
abdusco 2y ago
> make requests even if you don't have the .proto around Like this? > grpcurl -d '{"id": 1234, "tags": ["foo","bar"]}' \ grpc.server.com:443 my.custom.server.Service/Method How is that even possible? How could grpcurl know how to translate your request to binary?
- ainar-g 2y ago
  If I recall correctly, ProtoBuf has a reflection layer, and it's probably using that.
- BobbyJo 2y ago
  I could be wrong, but it is probably using json encoding for the object body, and implementing the transport for grpc instead of http. Proto objects support json encode/decode by default in all the implementations I've seen. https://grpc.io/blog/grpc-with-json/ https://grpc.io/blog/grpc-with-json/
jakjak123 2y ago
I just build a cli in Java or Go. It literally takes minutes to build a client.

mattboardman 2y ago

My biggest complaint with gRPC is proto3 making all nested type fields optional while making primitives always present with default values. gRPC is contract based so it makes no sense to me that you can't require a field. This is especially painful from an ergonomics viewpoint. You have to null check every field with a non primitive type.

dudus 2y ago
If I remember correctly the initial version allowed required fields but it caused all sorts of problems when trying to migrate protos because a new required fields breaks all consumers almost by definition. So updating protos in isolation becomes tricky. The problem went away with all optional fields so it was decided the headache wasn't worth it.
- bunderbunder 2y ago
  I used to work at a company that used proto2 as part of a homegrown RPC system that predated gRPC. Our coding standards strongly discouraged making anything but key fields required, for exactly this reason. They were just too much of a maintenance burden in the long run. I suspect that not having nullable fields, though, is just a case of letting an implementation detail, keeping the message representation compatible with C structs in the core implementation, bleed into the high-level interface. That design decision is just dripping with "C++ programmers getting twitchy about performance concerns" vibes.
  - fyrn_ 2y ago
    Zoox?
- fisian 2y ago
  That decision seems practical (especially at Google scale). I think the main problem with it, is that you cannot distinguish if the field has the default value or just wasn't set (which is just error prone). However, there are solutions to this, that add very little overhead to the code and to message size (see e.g. [1]). [1]: https://protobuf.dev/programming-guides/dos-donts/ https://protobuf.dev/programming-guides/dos-donts/

cryptonector 2y ago

> Bad tooling Lolwut. This is what was always said about ASN.1 and the reason that this wheel has to be reinvented periodically.

throwaway894345 2y ago
It can be true for both ASN.1 and gRPC? Moreover, definitions of "bad" can vary.
- cryptonector 2y ago
  Before inventing a new serialization protocol it would be good to first study the field and pick an existing protocol that ticks all the right boxes, and if the tooling isn't very good then write new tooling -- you'd have to write new tooling for a new protocol anyways, but if you can find a good enough existing one then you don't also have to write a spec, thus saving you a lot of time.

bunderbunder 2y ago

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.

neonsunset 2y ago
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.
- pixl97 2y ago
  >It is possible to do quite well, as demonstrated by {one of the other largest companies in the world} FTFY
- svaha1728 2y ago
  No disrespect to the other developers on the team, but James Newton-King is no ordinary developer.
- kodablah 2y ago
  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 https://github.com/grpc/grpc-dotnet/issues/303

epgui 2y ago

A lot of this kind of criticism rubs me the wrong way, especially complaining about having to use words or maths concepts, or having to learn new things. That's often not really a statement on the inherent virtue of a tool, and more of a statement on the familiarity of the author. I don't want to sound flippant, but if you don't want to learn new things, don't use new tools :D

usrnm 2y ago
Sending a request and getting a response back is not a new concept, it's about as old as computer networks in general, and gRPC is the only framework that refers to this concept as "unary". This is the original argument from the article and I tend to agree with it
- epgui 2y ago
  Monads and functors are nothing new either, but that doesn’t mean giving them that name was a bad idea. Moreover, the term “unary” is used to distinguish from other, non-unary options: https://grpc.io/docs/what-is-grpc/core-concepts/ https://grpc.io/docs/what-is-grpc/core-concepts/
throwaway894345 2y ago
> I don't want to sound flippant, but if you don't want to learn new things, don't use new tools :D That's precisely the problem. The author wants to convince people (e.g., his colleagues) to use a new tool, but he has to convince them to learn a bunch of new things including a bunch of new things that aren't even necessary.

jscheel 2y ago

The tooling around gRPC with bazel when using python is so bad it’s almost impossible to work with, which is hilarious considering they both come from Google. Then I had additional problems getting it to work with Ruby. Then I had more problems getting it to work in k8s, because of load balancing with http/2. Combine those issues with a number of other problems I ran into with gRPC, and I ended up just building a small JSON-RPC implementation that fit our needs perfectly.

doctorpangloss 2y ago
Another point of view is, don't use Bazel. In my experience, Gradle is less of a headache and well supported.
- jscheel 2y ago
  For python? Gradle doesn't really support python.
  - kaba0 2y ago
    I mean, gradle is a generic build tool. It could support it, just as it can be used to compile C (I have done the latter).
- metadat 2y ago
  Gradle is an anti-pattern. Just stick with Maven and live a happy life. As someone who's used Gradle tons, 6 months ago I wrote in detail about why not gradle: https://news.ycombinator.com/item?id=38875936 https://news.ycombinator.com/item?id=38875936 Gradle still might less bad than Bazel, though.
  - EdwardDiego 2y ago
    I'm firmly in the Maven is better than Gradle camp. Yes, it's less flexible, that's why I like it. Gradle might be better if it wasn't a poorly documented Groovy/Kotlin DSL where everything is a closure, but I do like the fact that if you want to do something in Maven you need a plugin that couples to known points in the lifecycle. It makes it explicit what is doing what and where. And fully agree on the incredible pain of Gradle upgrades.

cyberax 2y ago

I'm surprised the author doesn't mention ConnectRPC: https://connectrpc.com/ https://connectrpc.com/ It solves ALL the problems of vanilla gRPC, and it even is compatible with the gRPC clients! It grew out of Twirp protocol, which I liked so much I made a C++ implementation: https://github.com/Cyberax/twirp-cpp https://github.com/Cyberax/twirp-cpp But ConnectRPC guys went further, and they built a complete infrastructure for RPC. Including a package manager (buf.build), integration with observability ( https://connectrpc.com/docs/go/observability/ https://connectrpc.com/docs/go/observability/ ). And most importantly, they also provide a library to do rich validation (mandatory fields, field limits, formats, etc): https://buf.build/bufbuild/protovalidate https://buf.build/bufbuild/protovalidate Oh, and for the unlimited message problem, you really need to use streaming. gRPC supports it, as does ConnectRPC.

athorax 2y ago
The author does mention it in the article and is also a contributor to supporting tooling https://github.com/sudorandom/protoc-gen-connect-openapi https://github.com/sudorandom/protoc-gen-connect-openapi
sudorandom 2y ago
Author here: I definitely should have been more explicit for my love of connectrpc, buf, protovalidate, etc. I do mention ConnectRPC but maybe not as loud as I could have. I definitely try to avoid confessing my love for ConnectRPC in every post, but sometimes it's hard not to because they've made such good strategic decisions that just make sense and round out the ecosystem so well.
- cyberax 2y ago
  My fault, I did read the article but I overlooked the ConnectRPC mention.

hot_gril 2y ago

I don't understand why there isn't an HTTP/1 mode for gRPC. Would cover the super common use case of client-to-server calls. Give people who already have your typical JSON-over-HTTP API something that's the same except more efficient and with a nicer API spec. You know what's ironic, Google AppEngine doesn't support HTTP/2. Actually a lot of platforms don't.

bunderbunder 2y ago
The streaming message transfer modes are the main thing that make it difficult.
- hot_gril 2y ago
  Streaming seems like it'd work without too much effort. It'd be less efficient for sure, but it's also not a very common use case.
  - bunderbunder 2y ago
    In general, I agree. But my understanding is that the problem isn't streaming in the abstract, it's supporting certain details of the streaming protocol outlined in the gRPC spec.

pcj-github 2y ago

FWIW I never worked at Google and I used protobuf / gRPC extensively at work and in nearly all of my side projects. Personally, I think overall it's great. I do wish trailers were an optional feature though.

kookamamie 2y ago

Insisting a particularly exotic flavor of HTTP(2) is its most severe design flaw, I think. Especially, as it could have worked in an agnostic manner, e.g. on top WebSockets.

sudorandom 2y ago
Author here: it's nerdy web trivia but HTTP trailers are actually in the HTTP/1.1 spec, although very few browsers, load balancers, programming languages, etc. implemented it at the time since it wasn't super useful for the web. You are definitely correct that it is an exotic feature that often gets forgotten about.

FridgeSeal 2y ago

> Why does gRPC have to use such a non-standard term for this that only mathematicians have an intuitive understanding of? I have to explain the term every time I use it. Who are you working with lol? Nobody I’ve worked with has struggled with this concept, and I’ve worked with a range of devs, including very junior and non-native-English speakers. > Also, it doesn’t pass my “send a friend a cURL example” test for any web API. Well yeah. It’s not really intended for that use-case? > The reliance on HTTP/2 initially limited gRPC’s reach, as not all platforms and browsers fully supported it Again, not the intended use-case. Where does this web-browsers-are-the-be-all-and-of-tech attitude come from? Not everything needs to be based around browser support. I do agree on http/3 support lacking though. > lack of a standardized JSON mapping Because JSON has an extremely anaemic set of types that either fail to encode the same semantics, or require all sorts of extra verbosity to encode. I have the opposite experience with protobuf: I know the schema, so I know what I expect to get valid data, I don’t need to rely on “look at the json to see if I got the field capitalisation right”. > It has made gRPC less accessible for developers accustomed to JSON-based APIs Because god forbid they ever had to learn anything new right? Nope, better for the rest of us to just constantly bend over backwards to support the darlings who “only know json” and apparently can’t learn anything else, ever. > Only google would think not solving dependency management is the solution to dependency management Extremely good point. Will definitely be looking at Buf the next time I touch GRPC things. GRPC is a lower-overhead, binary rpc for server-to-server or client-server use cases that want better performance and faster integration that a shared schema/IDL permits. Being able to drop in some proto files and automatically have a package with the methods available and not having to spend time wiring up url’s and writing types and parsing logic is amazing. Sorry it’s not a good fit for serving your webpage, criticising it for not being good at web stuff is like blaming a tank for not winning street races. GRPC isn’t without its issues and shortcomings- I’d like to see better enums and a stronger type system, and defs http/3 or raw quic transport.

lanstin 2y ago
I use protobuf to specify my protocol and then generate a swagger/openAPI spec then use some swagger codegen to generate rest client libraries. For a proxy server I have to fill in some stub methods to parse the json and turn it into a gRPC call but for the gRPC server there is some library that generates a rest service listener that just calls into the gRPC server code. It works fine. I had to annotate the proto file to say what REST path to use.

tgma 2y ago

gRPC is deliberately designed not to be dependent on protobuf for its message format. It can be used to transfer other serialization formats. However, the canonical stub generator, which is not hard to replace at all, assumes proto so when people hear gRPC they really think of Protobuf over gRPC. Most of the complaints should be directed at protobuf, with or without gRPC. The primary misfeature of gRPC itself, irrespective of protobuf, is relying on trailers for status code, which hindered its adoption in the context of web browser without an edge proxy that could translate gRPC and gRPC-web wire formats. That alone IMO hindered the universal applicability and adoption quite a bit.

bootloop 2y ago
Do you know of an example where this is done? I didn't know that and we are currently using a customized wire format (based on a patched Thrift), so I thought gRPC wouldn't be an option for us.
- tgma 2y ago
  I have done it in proprietary settings. Nothing off the top of my head. The gRPC libraries themselves are pretty straightforward. You just need to use thrift IDL parser to output stubs that use gRPC under the hood. The C++ one may be slightly more challenging to replace because extra care is needed to make sure protobuf message pipeline is zero-copy. Other languages are more trivial. One place to start would be to look at the gRPC protoc plugin and see how it’s outputting code and do something similar. Pretty lean code.
jakjak123 2y ago
This is the true design issue with gRPC as I see it. It would be way bigger without this. I love protobuf though, gRPC is just alright. At least gRPC makes it so much simpler to build powerful automation and tooling around it than the wild west of randomly created 'json'-ish REST-ish APIs.

cherryteastain 2y ago

For me, the breaking point was when I saw the C++ bindings unironically recommend [1] that you use terrible anti-patterns such as "delete this". I find it unlikely that all these incredibly well paid Google engineers are unaware how people avoid these anti-patterns in idiomatic C++ (by e.g. std::shared_ptr). The only remaining sensible explanation is that Google internal gRPC C++ tooling must have utilities that abstract away this ugly underbelly, which us mere mortals are not privy to. [1] https://grpc.io/docs/languages/cpp/callback/ https://grpc.io/docs/languages/cpp/callback/

deleted 2y ago

[deleted]

pjmlp 2y ago

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 doing gRPC are available in Visual Studio.

pjc50 2y ago
> 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)
- pjmlp 2y ago
  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.

camgunz 2y ago

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.

bitzun 2y ago

My main problems with grpc are threefold: - The implementation quality and practices vary a lot. The python library lacks features that the go library has because they are philosophically opposed to them. Protobuf/grpc version pinning between my dependencies has broken repeatedly for me. - If you are a services team, your consumers inherit a lot of difficult dependencies. Any normal json api does not do this, with openapi the team can use codegen or not. - The people who have been most hype to me in person about grpc repeat things like "It's just C structs on the wire" which is completely fucking wrong, or that protobuf is smaller than json which is a more situational benefit. My point being their "opinion" is uninformed and band-wagoning. This article gave me some new options for dunking on grpc if it's recommended.