@All like annotation for gRPC clients

[LarsSven]

Description

Feature request

I would love to have an annotation similar to @ALL for @Inject that generates a map/list of all gRPC clients defined in the application.properties. So if we defined an application.yml as follows:

quarkus:
  grpc:
    clients:
      container-runtime:
        ...
      executable-runtime:
        ...

Doing something like

@GrpcClients
Map<String, ActionService> clients

Would generate a map of name to client.

Use case

To exemplify why this may be useful, we essentially have a microservice that receives an execution graph of requests that should be sent to some gRPC servers. The microservice itself does not care about which gRPC servers there are, it just gets the name of the server as part of the requests. In order to implement this, we currently need to hardcode every server using @GrpcClient, which means that if we need to add another gRPC server, we need to release a new application version of the microservice, since all available gRPC servers are hardcoded in the code. Instead, it would be much nicer to just deploy the new gRPC server, update the application.yml with the host/port of the new server, without needing to update the source code. But for that, we need to dynamically retrieve all gRPC clients from the application config.

Implementation ideas

No response

[quarkus-bot]

/cc @alesj (grpc), @cescoffier (grpc)

[cescoffier]

We could provide the names, but we cannot rely on CDI because they all use different interfaces.
Actually, you might be able to inject all the Bindable beans. @alesj WDYT?

[alesj]

@cescoffier I guess a new annotation + only allow to inject into Map?
Let me see what I can come up with ...

[LarsSven]

For full support I think you'd need to support different interfaces, but for us for example all clients use the same protobuf spec so they use the same client interface.

But yeah a proper generalised implementation could indeed encounter multiple gRPC clients that have a different protobuf spec.

[LarsSven]

@cescoffier @alesj just to ask, do you think this would realistically be implemented in the near future for Quarkus, or more something that will be hard to do or will be lower priority? I am mainly asking because we need to decide for our service whether to rely on a feature like this or to switch to a different strategy.