-
-
Notifications
You must be signed in to change notification settings - Fork 288
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
Add message type to describe Event/Command/Other #1074
Comments
Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request. |
Hey! @rj93 can you tell me exactly how to give the message the type server or client ? I want to contribute to this issue. Thanks !!😊 |
Hey @rj93 , I would like to take up this issue. |
Hi @rj93 ! I'm Ashutosh goyal, a contributor eager to help with the AsyncAPI project. I’m excited to be involved in improving the specifications and learning more about the project. Looking forward to collaborating with everyone here! |
Hey @rj93! This is a great idea—it could make AsyncAPI specs more expressive and improve code generation. Message classification is a key part of event-driven architectures, so formalizing it in the spec makes a lot of sense. Building on this, what do you think about adding a
This could make things clearer for code generators while still being flexible for different messaging patterns. We’d also need to decide if it should be a required field or optional. I’d love to contribute and help work through the technical details! 🚀 |
Messages are frequently either considered to be Commands or Events, there is even a brief section in the docs about it.
However the message spec doesn't currently have anyway to differnaitate these types of messages.
This could potentially be useful in the code generators to either implement "server" or "client" implementations.
Servers would generate the listeners for commands, and emitters for events. While clients would generate the inverse.
The text was updated successfully, but these errors were encountered: