gRPC: 5 Years Later, Is It Still Worth It?
kostyay.com
gRPC: 5 Years Later, Is It Still Worth It?
1–10 of 37 posts
Re: gRPC: 5 Years Later, Is It Still Worth It?
#2I've been working on OpenTelemetry for a few years now, and regularly field questions from end-users wondering why data doesn't seem to end up where they want it. I'd say that at least half the time, switching from the gRPC exporter to the HTTP exporter simply solves it.
Re: gRPC: 5 Years Later, Is It Still Worth It?
#3I've been working on OpenTelemetry for a few years now, and regularly field questions from end-users wondering why data doesn't seem to end up where they want it. I'd say that at least half the time, switching from the gRPC exporter to the HTTP exporter simply solves it.
Interesting (as someone just getting into otel) - what is causing grpc exporters to have this loss? Is this loss more by using grpc over the internet vs http or even internally within a network/vpc?
Re: gRPC: 5 Years Later, Is It Still Worth It?
#4I love protobufs as a type-safe way of defining messages and providing auto-generated clients across languages.
I can't stand gRPC. It's such a Google-developed product and protocol that trying to use it in a simpler system (e.g. everyone else) is frustrating at best, and infuriating at worst. Everything is custom and different than what you're expecting to deal with when at its core, it is still just HTTP.
Something like Twirp (https://github.com/twitchtv/twirp) is so much better. Use existing transports and protocols, then everything else Just Works.
Re: gRPC: 5 Years Later, Is It Still Worth It?
#5[flagged]
Re: gRPC: 5 Years Later, Is It Still Worth It?
#6In years of developing pretty complex products with gRPC I don't think we've ever run into an issue or sharp corner.
Having the libraries generating relatively optimized message parsers and server implementations and just throwing middlewares around them, with easy support for deprecating fields, enums, and a bunch of other goodies - all been a huge help and productivity gain. So much can be done by just understanding the gRPC config settings and throwing some bog-standard middlewares around things.
Re: gRPC: 5 Years Later, Is It Still Worth It?
#7Things I've learned using gRPC for ~10 years:
1. I really like gRPC and protos for the codegen capabilities. APIs I've worked on that use gRPC have always been really easy to extend. I am always tempted to hand-roll http.Handle("/foo", func(w http.ResponseWriter, req *http.Request) { ... }), but gRPC is even easier than this.
2. grpc-web never worked well for me. It's hard to debug; in the browser's inspector you just have serialized protos instead of JSON, and developers find this hard to debug. Few people know about `protoc --decode[-raw]` options. (This comes up a lot when working with protos; you have binary or base64-encoded protos but just want key/value pairs. I ended up adding a command to our CLI to do this for you.)
I also thought the client side of the equation was a little too bloated. webpack and friends never tree-shook out code we didn't call, and as a result, the client bundle was pretty giant for how simple of an app we had. There are also too many protoc plugins for the frontend, and I feel like whenever a team goes looking for one, they pick the wrong one. I am sure I have picked the wrong one multiple times. After many attempts at my last job, I found the sane Typescript one. But at my current job, a team started using gRPC and picked the other one, which caused them a lot of pain.
3. grpc-gateway works pretty well, though. Like grpc-web, it suffers from promised HTTP features never being implemented, so it can't implement all of gRPC. (gRPC is really just bidirectional RPCs, but you can restrict what you do to have unary RPCs, server streaming RPCs, client streaming RPCs, and bidirectional RPCs. The web really only handles unary and server streaming. grpc-gateway doesn't remove these grpc-web limitations.)
But overall, I like it a lot for REST APIs. If I were building a new REST API from scratch today, it would be gRPC + grpc-gateway. I like protos for specifying how the API works, and grpc-gateway turns it into a Swagger file that normal developers can understand. No complaints whatsoever with any of it. (buf is unnecessary, and I feel like they just PR'd themselves into the documentation to sound like it's required, but honestly if it helps people, good for them. I just have a hand-crafted protoc invocation that works perfectly.)
4. For plain server-to-server communication, you'd expect gRPC to work fine, but you learn that there are middleboxes that still don't support HTTP/2. One problem that we have is that our CLI uses gRPC to talk to our server. Customers self-host all of this, and often work at companies that break gRPC because their middleboxes don't support HTTP/2. (I'll point out here that HTTP/3 is the current version of HTTP.) We have Zscaler at work and this mostly affects our internal customers. (We got acquired and had these conditions added 8 years into the development cycle, so we didn't anticipate them, obviously.) But if we were starting all over today, I'd use grpc-gateway-over-http1.1 instead of grpc-over-http2. The API would adjust accordingly; I wouldn't have bidirectional RPCs, but RPCs that simulate them. Something like a create session RPC, then a unary call to add another message to the session, and a unary call that returns when a message is ready. It sucks, but that's all that HTTP/1.1 in the browser really offers, and that's the maximum web compatibility level that works in Corporate America these days.
5. Some details are really confusing and opaque to end users trying to debug things. Someone set up a proxy. They connected to dns:///example.com and the proxy doesn't work properly. This is because gRPC resolves example.com and dials the returned IP addresses, and sets :authority to the IP addresses and not the hostname. You have to use passthrough:///example.com to have the HTTP machinery make an HTTP request for example.com/foopb/Foo.Method. Maybe this is Go specific, but it always confuses people. A little too many features available out of the box, that again work great on networks you control, but poorly on networks that your employer controls.
Re: gRPC: 5 Years Later, Is It Still Worth It?
#8This was never worth it. From the beginning. Large corporations like Google try to lock developers into technology. They try to promote themselves as cool tech to job applicants. For example .NET from Microsoft, Swift from Apple, on and on. There are a few examples of good stuff coming out, but in general just say no...
And certainly if you want to get a job at one of these places, learn their technology, but then once even that company stops using it, where are you?
Re: gRPC: 5 Years Later, Is It Still Worth It?
#9I love protobufs as a type-safe way of defining messages and providing auto-generated clients across languages. I can't stand gRPC. It's such a Google-developed product and protocol that trying to use it in a simpler system (e.g. everyone else) is frustrating at best, and infuriating at worst. Everything is custom and different than what you're expecting to deal with when at its core, it is still just HTTP. Something…
Twirp is lovely, we kind of hit a wall when using it internally because it doesn't have a streaming story: https://github.com/twitchtv/twirp/issues/3
If you don't need to stream data it is excellent.
Re: gRPC: 5 Years Later, Is It Still Worth It?
#10[flagged]
[deleted]