-
I'm surprised the author doesn't mention ConnectRPC: 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
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/ ).
And most importantly, they also provide a library to do rich validation (mandatory fields, field limits, formats, etc): https://buf.build/bufbuild/protovalidate
Oh, and for the unlimited message problem, you really need to use streaming. gRPC supports it, as does ConnectRPC.
-
InfluxDB
InfluxDB high-performance time series database. Collect, organize, and act on massive volumes of high-resolution data to power real-time intelligent systems.
-
-
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
[2] https://x.com/awalterschulze/status/1584553056100057088
-
-
> Protobuf is intentionally designed to NOT require any parsing at all.
As others have mentioned, this is simply not the case, and the VARINT encoding is a trivial counterexample.
It is this required decoding/parsing that (largely) distinguishes protobuf from Google's flatbuffers:
https://github.com/google/flatbuffers
https://flatbuffers.dev/
Cap'n Proto (developed by Kenton Varda, the former Google engineer who, while at Google, re-wrote/refactored Google's protobuf to later open source it as the library we all know today) is another example of zero-copy (de)serialization.
-
I'm surprised the author doesn't mention ConnectRPC: 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
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/ ).
And most importantly, they also provide a library to do rich validation (mandatory fields, field limits, formats, etc): https://buf.build/bufbuild/protovalidate
Oh, and for the unlimited message problem, you really need to use streaming. gRPC supports it, as does ConnectRPC.
-
I'm surprised the author doesn't mention ConnectRPC: 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
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/ ).
And most importantly, they also provide a library to do rich validation (mandatory fields, field limits, formats, etc): https://buf.build/bufbuild/protovalidate
Oh, and for the unlimited message problem, you really need to use streaming. gRPC supports it, as does ConnectRPC.
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
protoc-gen-connect-openapi
Plugin for generating OpenAPIv3 from protobufs matching the Connect RPC interface
The author does mention it in the article and is also a contributor to supporting tooling
https://github.com/sudorandom/protoc-gen-connect-openapi
-
-
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
-
Go's GC wasn't really made with high throughput in mind. It's a language that doesn't scale to take advantage of beefy nodes and has weak compiler. I suppose the Google's vision for it is to "crank the replica count up". gRPC servers based on top of ASP.NET Core, Java Vert.X and Rust Thruster will provide you with much higher throughput on multi-core nodes with .NET showing the best P99 latency in that scenario.
https://github.com/LesnyRumcajs/grpc_bench/discussions/441
-
> Except for our most used language, Java.
The official Java implementation of grpc looks like abandonware. Out of the box the builder includes an annotation (javax.annotation.Generated) that was deprecated in 2019:
https://github.com/grpc/grpc-java/issues/9179
This gives me serious pause.
