gRPC: The Bad Parts
kmcd.dev
gRPC: The Bad Parts
1–10 of 230 posts
Re: gRPC: The Bad Parts
#2One 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
Re: gRPC: The Bad Parts
#3I 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).
Re: gRPC: The Bad Parts
#4"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.
Re: gRPC: The Bad Parts
#5I 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).
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.
Re: gRPC: The Bad Parts
#6I do generally agree the tooling sucks, but as mentioned, buf and the connectrpc ecosystem have made it much easier to get things going.
Re: gRPC: The Bad Parts
#7One 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
same in java
Re: gRPC: The Bad Parts
#8Its pretty ironic but Microsoft decided to lean into gRPC support for C#/ASP.NET and its honestly really well done and has great devx.
Re: gRPC: The Bad Parts
#9Yes, 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.
Re: gRPC: The Bad Parts
#10A 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
Note: usually you need Grpc.Client and Google.Protobuf too but that's two `dotnet add package`s away.