[FEATURE REQUEST] Message-classes/Topic-classes

[RobertDiebels]

Is your feature request related to a problem? Please describe.
I believe it would be useful to allow protocol specific settings for topics or messages, much like the Kubernetes spec does for persistent volumes in the form of Storage-classes.

In this case I would like to request a feature for publishing messages directly to a queue for the AMQP protocol. As well as the possibility to add a default queue and exchange. Allowing this would cover many desirable use-cases.

Can't it be tackled using specification extensions?
I believe that if you support a protocol you should support all its features. So in this case it would not suffice.

Describe the solution you'd like
I would suggest something similar to storage-classes in Kubernetes. Think of it like a message-class/topic-class. Adding a layer of abstraction so the topic-class can be reused.

Below I've added an example for topic-classes something similar could be added for messages if desirable. In it I've added a topic-classes attribute to the components property. It contains a default-class which defines a protocol which to me is akin to a provisioner in Kubernetes storage-classes. The class states it is the default-class for all topics however, topics can override it by specifying their preferred class.
The default-class specifies a queue which applies to both subscribing and publishing, unless the queue is overridden in the subscribe or publish properties of the class. If the properties do not specify a queue the default is used.

asyncapi: '1.3.0'
info:
  title: Example API
  version: '1.0.0'
  description: |
    Example API.
  license:
    name: Apache 2.0
    url: 'https://www.apache.org/licenses/LICENSE-2.0'

servers:
- url: some.url.net
  scheme: amqp
  description: Example broker
  variables:
    port:
      description: Secure connection (TLS) is available through port 8883.
      default: '1883'
      enum:
      - '1883'
      - '8883'

topics:
  example-topic:
    class: 
      $ref: '#/components/topic-classes/default-class'
    publish:
      $ref: '#/components/messages/example'
  example-message-class-topic:
    publish:
      $ref: '#/components/messages/message-class-example'

components:
  messages:
    example:
      summary: An example message.
      payload:
        $ref: "#/components/schemas/example"
    message-class-example:
      summary: An example message.
      class: '#/components/message-classes/rpc-class'
        $ref: 
      payload:
        $ref: "#/components/schemas/example"
  schemas:
    example:
      type: object
      properties:
        example:
          type: sting
          description: An example string
  topic-classes:
    default-class: 
      scheme: amqp
      default: true
      queue:
        name: example-queue
      publish: 
        direct-to-queue: true
        routing-key: routed-to-something
#      exchange: <- Defining exchange specifics would also be possible, just not when publishing directly to a queue.
#        name: overriding-exchange 
#        type: fanout, direct, topic
      subscribe:
        binding-key: routed-to-something-else
        queue:
          name: overriding-queue
  message-classes:
    rpc-class:
      scheme: ampq
      delivery_mode: 2
      content_type: application/json
      reply_to: rpc-queue

Describe alternatives you've considered
I've considered adding extensions which tools could read. Though I feel it would not be a proper solution due to the reasons I've stated above. If a specification supports a protocol it should support the protocols features.

Additional context
Some benefits of topic-classes:

1. Adding topic-classes/message-classes opens up the specification to many more protocol-specific use-cases.
2. Topic-classes would not be a breaking change, it would simply add functionality as new properties.
3. I believe this proposal would tie into Consideration: Protocol specific message objects #42 as it has a few commonalities.
4. Topic-classes/message-classes can be reused across multiple topics/messages.
5. Message-classes could be used to implement features like RPC in AMQP. I believe this is similar to the feature-request in Support request/reply pattern #94 not certain though.

Let me know what you think.

[fmvilas]

It's a great feature request, thanks for taking the time and effort to explain it. It was definitely planned and we're going to work on it as our next milestone. Check out our roadmap: https://github.com/asyncapi/asyncapi/milestone/2

I'll ping you when we have a first draft implementation. Thanks!

[RobertDiebels]

@fmvilas Nice! Thanks for the quick response. I'll keep my eye out for the ping 😄

[asyncapi-bot]

🎉 This issue has been resolved in version 1.0.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀