[FEATURE] Improve routing key and queue definitions

[kvaleev]

Why do we need this improvement?

Hello,

Even in simple cases, I am always struggling to define the specification with AMQP bindings. I think either the bindings definitions should be changed, or we need to have documented the correct way to specify it.

Imagine a case: we have a service that sends events to a broker with some routing key that has a parameter (say event.type.{id}) to an exchange Events, and receives other events from some queue queue-for-service-{serviceID}. How can I specify it with current embeddings:

channels:
    sendingEventsChannel:
        address: 'event.type.{id}'
        parameters:
            id:
        ...
        bindings:
            amqp:
                is: routingKey # OK, this means that the address is a routing key
                exchange:
                    name: Events
                    type: topic
        messages:
            eventMessage:
                bindings:
                    amqp:
                        messageType: 'event.type' # Why can't I use parameters here? 
                                                  # Why do I have to write it again if it's already in the address?
        ...
    receivingEventsChannel:
        address: 'queue-for-service-{serviceID}'
        parameters:
            serviceID:
        ...
        bindings:
            amqp:
                is: routingKey # OK, I can assume that the address is a queue name, similar to a routing key.
                queue:
                    name: my-queue-name # But no, I need to set queue name again. 
                                        # What is address then? And again, I can't use parameters here. 
                                        # Also, why can't I define which exchange the queue should bind to?
        messages:
            eventMessage:
                bindings:
                    amqp:
                        messageType: 'event.type' # Why can't I use parameters here?
        ...

To summarise:

1. Why is the address used for the routing key binding but not for the queue?
2. What is the purpose of the address for the queue binding if the queue name has to be explicitly set again?
3. Why can't we use parameters in bindings?
4. Why can't we specify which exchange the queue should bind to?

How will this change help?

To have a clear and consistent description of routing keys and queues used.

Screenshots

No response

How could it be implemented/designed?

If it helps, I can suggest some changes to the bindings specification that I think might make it clearer.

🚧 Breaking changes

Yes

👀 Have you checked for similar open issues?

• [X] I checked and didn't find a similar issue

🏢 Have you read the Contributing Guidelines?

• [X] I have read the Contributing Guidelines

Are you willing to work on this issue?

Yes I am willing to submit a PR!

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart: