Load-balancing ClientConn : Not an interface

[CMajeri]

Hello,
We are trying to make a generic client-side load-balancer for grpc. The way we thought of doing this would have been to wrap multiple ClientConn inside a load-balancer, that would itself be treated as a ClientConn.

However, ClientConn is a struct, which makes it impractical for our load-balancer to try and emulate. If it was exposed as an interface, we could call a NewClient directly on the load-balanced connections, but as is, we can load-balance over clients directly, but this approach is less generic and requires some groundwork for different services.

Are there reasons for why ClientConn is a struct and not an interface? If so, could you suggest the grpc-friendly way of doing what we are trying to achieve?

Thanks.

This might be related to #1105

[dfawley]

That's a reasonable suggestion, but it would require some changes to the API, which we would rather avoid unless there's a strong need.

gRPC implements support for load-balancing internally, including custom load balancing logic (godoc) -- if you were already aware of this, could you explain why that is not sufficient for your needs?

[CMajeri]

That was a long week! I'm sorry.

I had the time to review and test out the grpc load-balancing, and it works well enough for our needs, and after exploring the source, it's simple enough to work with. Thank you for directing me to it!

We also need to implement breaking and throttling patterns, but those are easy enough to just wrap around. Thanks again.

[dfawley]

Great to hear, and thanks for following up. Note that we will be changing this API in the next couple months to enable some additional required gRPC features like swapping the balancer at runtime based on service config updates. There should be a gRFC out for this very soon (keep an eye out for pull requests in the proposal repo). Migrating an existing balancer to the new API isn't expected to be difficult.

[dfawley]

I think we may actually be able to do this without significant compatibility changes. Reopening to investigate.

[dfawley]

Actually, I'll reopen this until the protoc-gen-go changes are merged.

[dfawley]

The protoc-gen-go changes have been merged! 🎉

golang/protobuf#1025
https://go-review.googlesource.com/c/protobuf/+/216399

I'll update our .pb.go files shortly.