clientFactory: go supports generic type since 1.18. Is some way to offer clientfactory to create client

[someview]

Please see the FAQ in our main README.md before submitting your issue.

Use case(s) - what problem will this feature solve?

Do not need different client defintion,unify and simplify code,decoupling client from business

Proposed Solution

use ClientFactory[T any] to create client, insteadOf using proto-gen-go-grpc plugin.

Alternatives Considered

In most cases Client won't be destoryed once it is created, so we can create client just like other languages like csharp or java. We can offer a generic-type plugin to generate client.

Additional Context

That means, we just need msg definetion or contract,no bind with grpc client

[easwars]

gRPC-Go does not have a client factory to begin with. The issue description does not make a whole lot of sense to me. Please explain your issue clearly (possible with code samples).

[someview]

Under the micro-service architecture we must write a wide variety of clients.such as NewAuthClient,NewChatClient. The code was generated by proto-gen-go-grpc plugin.That means, business strongly depends on these client code. Commonly, we should separate the third package from application.

// now ,create client  like this:
conn, err:=grpc.Dial()
authClient :=NewAuthClient(conn)
chatClient := NewChatClient(conn)
...
// expected
authClient := ClientFactory.create[AuthContract]()
chatClient := ClientFactory.create[ChatContract]()

The benefits are obvious:

1. code is relatively uniform,why we must know a variety of clientName???
2. Easy to migrate and maintain when using other protocols There is some difficult to go generate client code by dynamic reflection,but relatively, how about offer clientFactory to create client by the clientfactory plugin offically ,which implements contract

[easwars]

The code generated by protoc-gen-go-grpc has served us and our users reasonably well up to this point, and we have not heard any concerns about using this generated code in a micro-services architecture. We do not see any advantage in the approach that you've suggested here, over the existing approach.

code is relatively uniform,why we must know a variety of clientName???

If you are communicating with a service, you need to know what service you are communicating with. And there is a single client type per service with all the methods exposed in that service. Why is this approach sub-optimal to what you have? And why would we want to change all existing usages?

[github-actions[bot]]

This issue is labeled as requiring an update from the reporter, and no update has been received after 6 days. If no update is provided in the next 7 days, this issue will be automatically closed.