gRPC client - dynamic host and port

[mariuszbozek]

Hi,
I would like to use gRPC for communication between instances of this same microservice. I can't find the option to create a gRPC client with a dynamic host and port. There is any chance to creating a gRPC client in the code with a defined host and port (not by application.properties)

[quarkus-bot[bot]]

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

[cescoffier]

You can create the channel, but you would be totally on your own without any management done by Quarkus.

[alesj]

with a dynamic host and port

What kind of "dynamic-ity" do you have in mind?

I guess it should work if you have 2 instances of the same client,
but simply named differently,
and you wire each to a different instance of the same service.
If that is dynamic enough ...

[mariuszbozek]

I think that @cescoffier answer is what I'm looking for.

[alesj]

I think that @cescoffier answer is what I'm looking for.

Well dunno if that's the best way to go ... as then you loose all the fancy Quarkus setup:

• no interceptors, no load-balancing ootb, manual security config, ...

OK, it's doable, but just saying / asking what would you need, hence we could find an easier way.

[mariuszbozek]

OK, it's doable, but just saying / asking what would you need, hence we could find an easier way.

Ok, I will be more clear. I would like to add the gRPC layer to sync data from Kafka State Store. When I have one instance is pretty easy but when I have min. 2 instances of this same service each service has its own state store. When I use interactive queries I have to be sure that I will return to UI (frontend) all needed data (from all instances). The service is deployed on Kubernetes so I have a dynamic IP address for each pod that's why I need a dynamic gRPC client

[alesj]

What you need sounds to me similar to what I implemented here:

• https://github.com/Apicurio/apicurio-registry/tree/1.3.x/utils/streams/src/main/java/io/apicurio/registry/utils/streams

Afais, i's just the other way around -- state store being smart enough to be distributed,
instead of state store syncing to nodes.