[deleted]
gRPC: 5 Years Later, Is It Still Worth It?
11–20 of 37 posts
Re: gRPC: 5 Years Later, Is It Still Worth It?
#12I'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?
The exporters themselves are usually fine, but it's usually something in their own network where gRPC traffic gets dropped somehow. Sometimes it's a load balance, sometimes it's something else.
Re: gRPC: 5 Years Later, Is It Still Worth It?
#13If you're picking communication protocols for your API endpoints, you're doing it wrong.
The ideal API supports `/api/call.json` and `/api/call.csv` and `/api/call.arrow` as well as `/api/call.grpc`, and the only thing that differs between these is the serializer (which is standardized and very well tested).
If the App is buggy, I want to (1) check what API calls it's making (2) be able to run those API calls myself, which is why I (ideally) need a text-based (human-readable) format.
Re: gRPC: 5 Years Later, Is It Still Worth It?
#14I 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…
Yea, and the code gen (for Go at least) very clearly assumes you're using a monorepo and how dare you think of doing anything else you monster.
E.g. there's a type registry, which means you can't ever have the same proto type compiled by two different configs (it'll panic at import time). In a monorepo that's (potentially) fine, but for the rest of the world it means libraries can't embed the generated code that they rely on (if the spec is shared), which means they can't customize it (no perf/size/etc tradeoff possible), can't depend on different versions of codegen or .proto files (despite code clearly needing specific versions, and breaking changes to the generated code are somewhat common), can't have convenience plugins for things that would benefit from it, etc.
And all of this to support... an almost-completely-unused text protocol. And `google.protobuf.Any` auto-return-value-typing, but tbh I think that's simply a bad feature, and it would be better modeled as a per Any deserialize call registry, where you can do whatever the heck you like (or not use it, and just `.UnmarshalTo(&out)` with the correct type).
---
What really gets my goat here is that none of this makes sense at all for a protocol. The whole point of having a language-and-implementation-agnostic binary protocol is to not be dependent on specific codegen / languages / etc, but per above the whole Go protobuf ecosystem is rigidly locked in at all times, and nearly every change is required to be a breaking change... and if you make that breaking change in a new Go module version, like you should, you immediately break anyone who uses two of them at once, so it must also always be a semver-violating breaking change.
Re: gRPC: 5 Years Later, Is It Still Worth It?
#15This 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 on…
So we should just never use some framework?
Re: gRPC: 5 Years Later, Is It Still Worth It?
#16This 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 on…
It locks you into a well-documented protocol, implemented by open source software?
Re: gRPC: 5 Years Later, Is It Still Worth It?
#17This 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 on…
One may argue about the reasons for (publishing) gRPC, but for .NET and swift the purpose was clear: They want to provide attractive options for developing applications on their respective platforms. If they succeeded is somewhat subjective. But I don't see what's bad about it, for the people who like their platforms.
Re: gRPC: 5 Years Later, Is It Still Worth It?
#18This 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 on…
It locks you into a well-documented protocol, implemented by open source software?
We should remain forever free, no chains on us, reinventing our own ad-hoc means of communication internally at each company! /s
Re: gRPC: 5 Years Later, Is It Still Worth It?
#19> We wanted to eliminate the need for each engineer to individually install protoc and multiple plugins and to make generating Go or TypeScript assets a single command a developer could execute.
Couldn't you just make protoc part of your project's git repo?
> This approach ensured that everyone on the team was using identical versions of these tools throughout their development process.
While this does enforce using the same version during development, it also introduces possible differences between code built during development and code built for production (if those are separate processes, as they should be in mature software).
Ideally, production builds should be hermetic and their inputs should only come from the committed source code and tools, not externally hosted ones that evolve independently.
Granted, with a tool as stable (and with such strictly defined interfaces) as protoc, perhaps the risk is minimal, but IMO this isn't a generalizable architecture.
Re: gRPC: 5 Years Later, Is It Still Worth It?
#20I haven't done any gRPC programming, but from what I understand it's a modern re-imagining of XML Web Services: you describe the contract and can generate client and server code based on it for different programming languages.
Early on in my career I worked on several projects that used WS-* "stack", and generally it was a very good experience. Once we had a project that was split between two subcontractor teams and each team worked on their portion of a system (a .NET application and an J2EE server) with API based on a common WSDL spec. The two teams (dozens of engineers on each side) worked independently for about a year, and after that they tried to run the two subsystems together, and it was really cool to see the parts "just click". There were some minor issues (like one side expected UTC timestamps and the other were sending localized time) but they took really little time to fix. The fact that two teams were not really talking to each other, were using different languages and libraries, relied on some manual testing through SoapUI and some mocks, and yet the whole thing even run at first attempt was very, very impressive!
WS-* was heavily criticized at the time: the standards and data formats were convoluted, the tooling beyond .NET and JVM was almost non-existent, Sun and Microsoft were not following the standards in their implementations and cared more about the interop with each other than about being standard-compliant. So, ultimately REST and JSON pushed the whole thing away. But I'm really happy to see people trying to replicate what was great about Web Services without making old mistakes, and I wish everyone involved all the best.
Which brings me to my actual question. Since software development history repeats / rhymes with itself every decade or two I now wonder if XML Web Services were not the first iteration of the formula? Was here another popular technology in 70s, 80s, or 90s that used had people describe an RPC contract and then used it to generate client and server glue code for it?
I know that both COM and CORBA used IDL to describe API, but I don't remember any code generation involved.