Proposal to be able to name channel item object

[bali182]

I'm trying to generate websocket code from AsyncAPI docs. I don't know if this is the case for other protocols too, but for websocket subscribe and publish is performed on the same connection. Currently only Operations (publish and subscribe) are nameable using operationId. For sockets it makes no sense to open 2 separate connection, one for publishing one for subscribing.

Let me demonstrate:

{
  "asyncapi": "2.0",
  "info": {
    "title": "",
    "version": ""
  },
  "components": {
    "schemas": {
      "NamedSimpleObject": {
        "type": "object",
        "required": [
          "stringProperty",
        ],
        "properties": {
          "stringProperty": {
            "type": "string"
          }
        }
      }
  },
  "channels": {
    "/test/{pathParam}": {
      "name": "TestChannel", // <---- This is what I'm asking for
      "parameters": {
        "pathParam": {
          "description": "test param",
          "schema": {
            "type": "string"
          }
        }
      },
      "subscribe": {
        "operationId": "subToTest",
        "summary": "Sub to test",
        "message": {
          "payload": {
            "$ref": "#/components/schemas/NamedSimpleObject"
          }
        }
      },
      "publish": {
        "operationId": "pubToTest",
        "summary": "Pub to test",
        "message": {
          "payload": {
            "$ref": "#/components/schemas/NamedSimpleObject"
          }
        }
      }
    }
  }
}

Now this could be generated as something like:

// Name based on my proposal
class TestChannel {
  private socket: WebSocket
  
  // Parameter from the channels ParameterObject
  constructor(pathParam: string) {
    this.socket = new WebSocket(`/test/${pathParam}`)
  }

  // subToTest is the operationId, NamedSimpleObject the message's schema, all good here
  subToTest(listener: (data: NamedSimpleObject) => void): void {
    this.socket.addEventListener('message', ({ data }) => {
      listener(JSON.parse(data))
    })
  }
  
  // pubToTest is the operationId, NamedSimpleObject the message's schema, all good here too
  pubToTest(data: NamedSimpleObject): void {
    this.socket.send(JSON.stringify(data))
  }
}

But without naming the channel it's not possible:

class ??? {
  // Parameter from the channels ParameterObject
  constructor(pathParam: string) {
    this.socket = new WebSocket(`/test/${pathParam}`)
  }

  // subToTest is the operationId, NamedSimpleObject the message's schema, all good here
  subToTest(listener: (data: NamedSimpleObject) => void): void {
    this.socket.addEventListener('message', ({ data }) => {
      listener(JSON.parse(data))
    })
  }
  
  // pubToTest is the operationId, NamedSimpleObject the message's schema, all good here too
  pubToTest(data: NamedSimpleObject): void {
    this.socket.send(JSON.stringify(data))
  }
}

So this would help to name whatever concept the generated code is using to encapsulate both subscribe and publish. It could be channelId too in case it needs to be inline with the operationId.

I'd just like to have a standard way for this and not come up with a home baked solution.

[fmvilas]

Interesting. I think you may also be interested in #618. It makes the channel Id mandatory.

[bali182]

@fmvilas I see this example in the issue you mentioned:

asyncapi: 3.0.0

channels:
  userSignedUp:
    address: user/signedup
    message:
      payload:
        type: object
        properties:
          email:
            type: string
            format: email

operations:
  sendUserSignedUpEvent:
    channel: userSignedUp
    action: send

I'm with you until the channel and operation separation and the channel id. But why is the message/payload defined in the channel itself? wouldn't that be an operation concern? Also does this example mean, that any new operation can only send the object defined in the channels message/payload?

[fmvilas]

In general, my response would be that it's a good practice to define what messages might circulate in a channel, however, I understand the limitations and that's why I added a section called "Further expansion > Override channel messages with operation-specific messages".

For questions related to the proposal please ask them in the #618 issue so other people can see it there too 🙏

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

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

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