One To Many Topic --> Message Scenario

[jedibatman]

After thoroughly reading the specification I was curious if it was intentional to only allow one message per subscribe or publish on a given topic item.

It seems to dictate a high level of verbosity related to topics that could be simplified in async apis that are primarily used for realtime updates via subscriptions. The specific scenario I am referring to is having a single topic that is used to publish multiple messages to subscribers -- similar to chat rooms.

Clarity in intention or thinking would be greatly appreciated.

[fmvilas]

Hey @jedibatman!

Thanks for opening the issue. I'm not clear with the use case (chat rooms). Does it mean that somehow your message contains to which chat room is the message going to be sent? For instance:

chatRoom: general
message: hello, how are u?

In this case I suppose your message always have the same structure. It is, it has a chatRoom property and a message property.

Am I missing something?

[jedibatman]

While what you have illustrated is correct, perhaps a chatroom is too simple of an example.

Suppose you have a bounded context of some kind -- let us take for example posts and comments on those posts. One might want to subscribe to all updates that are within the same context of a given post -- i.e. post.{:id}.

To further illustrate the concept, let us assume that a Post can be updated, users can create Comment's on a Post, and can additionally edit/update the Comment's that they created.

It would be valuable to allow the ability for a consumer of the async api to subscribe to a Post such that they can receive realtime updates (messages) that represent creation and updates to any Comment's that have an association to the given Post.

So in this scenario, there are at least 3 distinct events that can flow through the same topic:

• the update of a Post
• the creation of a Comment associated with a Post
• the updating of a Comment associated with a Post

Hopefully that provides enough elaboration to clarify the concept.

I think, to some extent, what I am advocating for is a message schema that has common attributes for all possible messages whereby the message can be identified to represent a specific event and contained within the message is the payload for said event. As an example:

{
  "topic": "topic.sometopic",
  "event": "some_event",
  "payload": {
    // the payload of "some_event"
  }
  // additional meta attributes that make up a message -- i.e. a correlation_id, sequence_id, etc.
}

[fmvilas]

Ok, understand what you mean. I'm gonna explain what's my approach in this case as it seems that you're moving the message broker logic to your app.

What you described before could be accomplished by just publishing/subscribing to a topic like post.{:id} and post.{:id}.comment. This will translate in AMQP to something like post.* and post.*.comment respectively.

Please make use of topics to route the messages properly, otherwise your application could receive much more messages than you can handle. In a system like the one you described, imagine you want to separate into 2 different services "Post CRUD" and "Comments CR". In the service in charge of managing posts you'll receive messages related to comments. At scale it could cause your service to get stuck trying to inspect the message to filter for the ones that contain a specific topic.

That said and even though I don't recommend the approach of multiple messages structures per topic, I'll consider adding it to the spec.

Thanks!

[fmvilas]

This will be addressed in v2 as it's a breaking change.

[ralcaide]

Hello, we have the same problem/requirement as @jedibatman. In our API, related to management of IoT devices, we receive several kind of messages over the same topic, for example all the actions messages go through the same topic. Also we publish several kind of messages in the same topic, for example all the measurements devices.
@fmvilas , is this, in your opinion, a bad design? will be this scenario accepted in V2.0.0? what is more or less the due date for V2.0.0?

Thanks

[fmvilas]

is this, in your opinion, a bad design?

Not necessarily bad, but I'd always recommend to take advantage of broker's routing features whenever possible for the reasons described above and also for performance. However, I understand AsyncAPI should not enforce any implementation details.

will be this scenario accepted in V2.0.0?

Yes, it's already accepted.

what is more or less the due date for V2.0.0?

TL;DR I don't know. I'll do my best.

I'm the only maintainer right now so it stongly depends on my time right now. I'm always looking for people wanting to join and dedicate some time to the project. If you have a need you might want to join and help prototype version 2.0.0.

Cheers!

[AnnaRedziak]

Hey, @fmvilas , this is very interesting. So, is there any progress in V.2.0.0 ? When will this feature be developed and available?

Kindest regards.

[fmvilas]

Hey @AnnaRedziak. Version 2 is stopped at the moment for personal reasons. Will try to come back to work as soon as I can. Thanks!

PS: This feature is already developed and available at v2 branch in case you want to start having a look.

[fmvilas]

I'm closing this issue as this feature can be achieved by fixing #58.

Example:

topics:
  myTopic:
    publish:
      anyOf:
        - $ref: '#/components/messages/message1'
        - $ref: '#/components/messages/message2'

[asyncapi-bot]

🎉 This issue has been resolved in version 1.0.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀