One To Many Topic --> Message Scenario about spec HOT 10 CLOSED

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.

from spec.

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?

from spec.

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.
}

from spec.

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!

from spec.

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

from spec.

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

from spec.

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!

from spec.

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.

from spec.

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'

from spec.

🎉 This issue has been resolved in version 1.0.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

from spec.