Ability to define a list of servers on which an operation is available

[mgiovann]

Problem

I want to represent that fact that my publish operation uses one URL (the URL of my message broker) and my subscribe operation uses another (the URL of my subscriber webhook).

Suggestion

The operation object should allow an optional list of server object names on which the operation is available

Example:

asyncapi: '2.3.0'
info:
  title: Account Service
  version: 1.0.0
  description: This service is in charge of processing user signups
servers:
  prod-broker:
    url: 'https://message-broker.example.com/events'
    protocol: http
  prod-webhook-1:
    url: 'https://subscription-webhook.example.com/events'
    protocol: http
  prod-webhook-2:
    url: 'https://subscription-webhook.example.com/events'
    protocol: http    
channels:
  user/signedup:
    subscribe:
      servers: ['prod-webhook-1', 'prod-webhook-2']
      message:
        $ref: '#/components/messages/UserSignedUp'
    publish:
      servers: ['prod-broker']
      message:
        $ref: '#/components/messages/UserSignedUp'
components:
  messages:
    UserSignedUp:
      payload:
        type: object
        properties:
          displayName:
            type: string
            description: Name of the user
          email:
            type: string
            format: email
            description: Email of the user   

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[smoya]

Hi @mgiovann, thanks for your RFC submission!

I wonder if, for your use case, you could create two different channels instead and specify a different server on each through the servers field.
Am I guessing right if I say you considered but discarded it because your channel address is still the same on both servers (user/signedup)?

AsyncAPI v3.0 will potentially include a big change in how Channels are identified. The address of the channel will be moved into a new field called address so you can have several channels pointing to the same address.
See #663. It might be the solution you are looking for?

[mgiovann]

Hi @smoya

That proposal would seem to solve our issue. Thanks for bringing it to our attention.

[smoya]

Do you agree we can then close this issue @mgiovann ?

[magicmatatjahu]

It's just that two channels don't quite solve the problem, because then there is a duplication of data - even in the case of version 3. We are thinking that a channel is just an address, but it's also information about bindings, parameters etc. and copying a channel we usually have to do a lot of references which is not very friendly from the UX level.

The ability to define servers at the level of operations is not such a strange idea and I would like to see it in the v3 version, of course, with a similar logic as with channel.servers:

• if servers are empty then the operation is available on every server
• if servers are not empty but channel.servers are empty then the operation is available on the servers in operation.servers
• if servers are not empty but also channel.servers are not empty then operation.servers must define servers from channel.servers as subset.

cc @smoya @mgiovann

[github-actions]

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

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 ❤️