Connect joins the CNCF: gRPC you can bet your business on

I only have the perspective of trying to add gRPC endpoints/servers to a large existing project, and... it's a nightmare primarily due to gRPC's insistence on using its own threads and refusal to integrate into an existing mainloop. This has caused bugs galore.

(This is a 1M LOC C project, shoehorning in the C++ gRPC implementation. C++ has also added to the pain due to poor readability and maintainability of the code.)

FWIW this buf.io/ConnectRPC thing posted here does not seem to help our problems at all.

My own experience has definitively been frustrating at times. I think the main issue is the lack of consistency and breakage between the different libraries/languages. Even minor version could cause issues when trying to create gRPC message definitions for different languages.

The documentation was also lacking when it came to arguments for each of the libraries.

I vaguely remembered wanted to change a small piece of a message and it took me a whole day of spelunking to figure out how to do it, browsing C++, Go codebases.

Take this with a grain of salt, this was a few years ago and things might have changed.

at least in grpc-java, we've ran into a number of issues with breaking changes that are incredibly subtle. For example, they changed the behavior of the DNS NameResolver to not periodically re-resolve endpoints. This meant that if your Loadbalancer didn't explicitly force re-resolution at some point (which isn't required for any other NameResolver implementation) then you could end up with stuck clients.

With rust’s tonic library and ts-protobuf on the client you no longer need a proxy.