Channel endpoint id resolved by expression language or env variable

[lifinsky]

Description
There is a need to launch a single microservice in multiple instances — for example, an auth service for back-office users and customers. This creates an issue with the static service name in the Symfony configuration, which can be worked around, but the channel name for internal asynchronous messages, used for queue name, must be unique. For the current Asynchronous attribute there’s a lack of endpointId substitution based on the service name through expression language, as was previously implemented in DbalParameter or Payload.

Example Current problem:

#[Asynchronous(MessagingChannel::Internal->value)]

enum MessagingChannel: string
{
    case Internal = 'auth_internal';
}

Possible solution (after expression language support):

#[Asynchronous(expression: "enum('MessagingChannel::Internal').endpointId()")]

[lifinsky]

In fact, then admin auth service and customer auth service will differ in the service name and, as a result, each instance will create AMQP queue for example admin_auth_internal and customer_auth_internal.

[dgafka]

Do you mean, each deployment of the same Services, should push to different queue? e.g.

I deploy BackOffice and for Message Handler X, it should go to backoffice_queue
I deploy Auth Service and for Message Handler X, it should go admin_queue

If so, why Auth Service would go through the same Message Handlers as Back Office Service?

[lifinsky]

@dgafka No. We wrote a universal user auth service that we want to deploy as a customer auth service and separately as a backoffice users auth service. Each, for example, has a separate Cognito user pool and its own settings, but they are within the same product. We want each service to have its own internal queue for AMQP (async)

[dgafka]

@lifinsky ok cool make sense now. So those Services does share same Rabbit instance, and you want to avoid conflicts. W'll take a look on what we can do here :)

[lifinsky]

@dgafka exactly, thanks

[lifinsky]

@dgafka You might consider mapping endpointId to the queue name via Ecotone AMQP configuration. Then the code will remain the same without having to support expression language

[lifinsky]

By default for existing code queue name will be generated using endpointId as name.

[dgafka]

You might consider mapping endpointId to the queue name via Ecotone AMQP configuration. Then the code will remain the same without having to support expression language

You should be able to use Dynamic Message Channels, to actually achieve what you're looking for. Then the application level code stays untouched by the changes in the infrastructure topology.

[lifinsky]

It seems to me that the problem here is that in the case of AMQP in the current implementation, the name of the endpoint channel is too strongly coupled with the infrastructure - precisely by the name of the queue. It would be correct for the AMQP configuration to allow the channel endpoint to be described. Then the attribute itself does not need any dynamics.