Routing Messages Based on Payload Schemas for Channels with Multiple send/receive Operations

[KhudaDad414]

Background:

With the introduction of support for multiple send/receive operations for the same channel, a new use-case has arisen that requires message routing based on payload schemas. This feature is particularly useful for WebSocket-based channels, where there is only one channel but multiple types of messages could be sent or received.

Problem Statement:

In the current system, if multiple send/receive operations are specified for a single channel, there is no built-in mechanism to route incoming or outgoing messages based on their payload schema.

Example:

Consider the following AsyncAPI specification for a Slack WebSocket API:

asyncapi: 3.0.0
info:
  title: Slack Websocket API
  version: 1.0.0
servers:
  Slack_WebSocket:
    host: wss-primary.slack.com
    protocol: wss
channels:
  SlackEventStream:
    servers:
      - $ref: "#/servers/Slack_WebSocket"
    address: /link/
    messages:
      SlackReactionAdded:
        $ref: "#/components/messages/SlackReactionAdded"
      GenericErrorPayload:
        $ref: "#/components/messages/GenericErrorPayload"
operations:
  HandleSlackReaction:
    reply:
      channel: 
        $ref: "#/channels/OpenAICompletion"
    action: receive
    channel:
      $ref: "#/channels/SlackEventStream"
    messages:
      - $ref: "#/components/messages/SlackReactionAdded"
  HandleError:
    action: receive
    channel:
      $ref: "#/channels/SlackEventStream"
    messages:
      - $ref: "#/components/messages/GenericErrorPayload"

In this example, messages that satisfy the SlackReactionAdded schema should be routed to the HandleSlackReaction operation, and messages that satisfy the GenericErrorPayload schema should be routed to the HandleError operation.

Proposed Solution:

1. Implement a message routing mechanism that inspects the payload schema of incoming or outgoing messages.
2. Route the message to the appropriate send/receive operation based on this inspection.
3. If no operation matches the payload schema, throw an error to indicate that the message could not be routed.

This feature will improve the flexibility and robustness of handling multiple types of messages on a single channel, especially for WebSocket-based APIs.

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

[KhudaDad414]

It would be better to ditch the entire routing based on channel and instead, route things based on the operations. this problem will be solved as a side effect.