-
-
Notifications
You must be signed in to change notification settings - Fork 262
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
One To Many Topic --> Message Scenario #38
Comments
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? |
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. To further illustrate the concept, let us assume that a It would be valuable to allow the ability for a consumer of the async api to subscribe to a So in this scenario, there are at least 3 distinct events that can flow through the same topic:
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 {
"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.
} |
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 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! |
This will be addressed in v2 as it's a breaking change. |
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. Thanks |
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.
Yes, it's already accepted.
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! |
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. |
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. |
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' |
🎉 This issue has been resolved in version 1.0.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
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.
The text was updated successfully, but these errors were encountered: