7 ms·
If I could go back in time I would stop myself from ever learning about gRPC. I was so into the dream, but years later way too many headaches. Don’t do it to y
by jdwyah 2y ago
If I could go back in time I would stop myself from ever learning about gRPC. I was so into the dream, but years later way too many headaches. Don’t do it to yourself.
Saying gRPC hides the internals is a joke. You’ll get internals all right, when you’re blasting debug logging trying to figure out what the f is going on causing 1/10 requests to fail and fine tuning 10-20 different poorly named and timeout / retry settings.
Hours lost fighting with maven plugins. Hours lost debugging weird deadline exceeded. Hours lost with LBs that don’t like the esoteric http2. Firewall pain meaning we had to use Standard api anyway. Crappy docs. Hours lost trying to get error messages that don’t suck into observability.
I wish I’d never heard of it.
- hedora 2y agoThe biggest project I’ve used it with was in Java. Validating the output of the bindings protoc generated was more verbose and error prone than hand serializing data would have been. The wire protocol is not type safe. It has type tags, but they reuse the same tags for multiple datatypes. Also, zig-zag integer encoding is slow. Anyway, it’s a terrible RPC library. Flatbuffer is the only one that I’ve encountered that is worse.
- TeeWEE 2y agoWhat do you mean with validating the bindings? GRPC is type safe. You don’t have to think about that part anymore. But as the article mentions OpenAPI is also an RPC library with stub generation. Manual parsing of the json is imho really Oldskool. But it depends on your use case. That’s the whole point: it depends.
- matrix87 2y ago> The wire protocol is not type safe. It has type tags, but they reuse the same tags for multiple datatypes. When is this ever an issue in practice? Why would the client read int32 but then all of a sudden decide to read uint32?
- sagarm 2y agoI guess backwards incompatible changes to the protocol? But yeah, don't do that if you're using protobuf; it's intentionally not robust to it.
- azemetre 2y agoWhat would you recommend doing instead?
- doctorpangloss 2y agoDo you need bidirectional streams? If so, you should write a bespoke protocol, on top of UDP, TCP or websockets. If you don't, use GraphQL.
- nithril 2y ago"Write a protocol and GraphQL", god damn it escalates quickly. Fortunately, there are intermediate steps.
- grumbelbart2 2y agoAny suggestions for a good RPC library?
- masterj 2y agoI have had a really good experience with https://connectrpc.com/ https://connectrpc.com/ so far. Buf is doing some interesting things in this space https://buf.build/docs/ecosystem/ https://buf.build/docs/ecosystem/
- zeroc8 2y agoI've used twitchtv/twirp with success. I like it because it's simple and doesn't reinvent itself over and over again.
- galangalalgol 2y agoWhat about songle directional streams? Graphql streams aren't widely supported yet are they? Graphql also strikes me as a weird alternative to protobufs as the latter works so hard for performance with binary payloads, and graphql is typically human readable bloaty text. And they aren't really queries, you can just choose to ignore parts of the return for a rpc.
- stickfigure 2y agoIMO the problem with gRPC isn't the protocol or the protobufs, but the terrible tooling - at least on the Java end. It generates shit code with awful developer ergonomics. When you run the protobuf builder... * The client stub is a concrete final class. It can't be mocked in tests. * When implementing a server, you have to extend a concrete class (not an interface). * The server method has an async method signature. Screws up AOP-oriented behavior like `@Transactional` * No support for exceptions. * Immutable value classes yes, but you have to construct them with builders. The net result is that if you want to use gRPC in your SOA, you have to write a lot of plumbing to hide the gRPC noise and get clean, testable code. There's no reason it has to be this way, but it is that way, and I don't want to write my own protobuf compiler. Thrift's rpc compiler has many of the same problems, plus some others. Sigh.
- rkagerer 2y agoAny alternatives that take a similar philosophy but get the tooling right?
- stickfigure 2y agoDepends what you mean by "similar philosophy". We (largeish household name though not thought of as a tech company) went through a pretty extensive review of the options late last year and standardized on this for our internal service<->service communication: https://github.com/stickfigure/trivet https://github.com/stickfigure/trivet It's the dumbest RPC protocol you can imagine, less than 400 lines of code. You publish a vanilla Java interface in a jar; you annotate the implementation with `@Remote` and make sure it's in the spring context. Other than a tiny bit of setup, that's pretty much it. The main downside is that it's based on Java serialization. For us this is fine, we already use serialization heavily and it's a known quantity for our team. Performance is "good enough". But you can't use this to expose public services or talk to nonjava services. For that we use plain old REST endpoints. The main upsides are developer ergonomics, easy testability, spring metrics/spans pass through remote calls transparently, and exceptions (with complete stacktraces) propagate to clients (even through multiple layers of remote calls). I wrote it some time ago. It's not for everyone. But when our team (well, the team making this decision for the company) looked at the proof-of-concepts, this is what everyone preferred.
- dtquad 2y agoYour problems has more to do with some implementations than the grpc/protobuf specs themselves. The modern .NET and C# experience with gRPC is so good that Microsoft has sunset its legacy RPC tech like WCF and gone all in on gRPC.
- divan 2y agoI use gRPC with Go+Dart stack for years and never experienced these issues. Is it something specific to Java+gRPC?
- robertlagrant 2y agoGo and Dart are probably the languages most likely to work well with gRPC, given their provenance.
- throwaway127482 2y agoGoogle has massive amounts of code written in Java so one would think the Java tooling would be excellent as well.
- 9rx 2y agoDoesn't Google mostly use Stubby internally, only bridging it with gRPC for certain public-facing services?
- p_l 2y agoGoogle also uses a completely different protocol stack to actually send Stubby/Protobuf/gRPC around, including protocols on the wire and bypassing the kernel (according to open access papers about PonyExpress etc)
- bborud 2y agoSince you mention Maven I'm going to make the assumption that you are using Java. I haven't used Java in quite a while. The last 8 years or so I've been programming Go. Your experience of gRPC seems to be very different from mine. How much of the difference in experience do you think might be down to Java and how much is down to gRPC as a technology?
- piva00 2y agoIt's not Java itself, it's design decisions on the tooling that Google provides for Java, mostly the protobuf-gen plugin. At my company we found some workarounds to the issues brought up on GP but it's annoying the tooling is a bit subpar.
- bborud 2y agoHave you tried the buf.build tools? Especially the remote code generation and package generation may make life easier for you. a couple of links https://buf.build/protocolbuffers/java?version=v29.3 https://buf.build/protocolbuffers/java?version=v29.3 https://buf.build/docs/bsr/generated-sdks/maven https://buf.build/docs/bsr/generated-sdks/maven
- drtse4 2y agoAs someone that used it for years with the same problems he describes... spot on analysis, the library does too much for you (e.g. reconnection handling) and handling even basic recovery is a bit a nuisance for newbies. And yes, when you get random failures good luck figuring out that maybe is just a router in the middle of the path dropping packets because their http2 filtering is full of bugs. I like a lot of things about it and used it extensively instead of the inferior REST alternative, but I recommend to be aware of the limitations/nuisances. Not all issues will be simply solved looking at stackoverflow.