[FEATURE] Introduces new functionality (complete pub/sub pattern) that wasn't fully demonstrated before. #1967
Description
Why do we need this improvement?
It enhances the example to better demonstrate AsyncAPI capabilities through
- Multiple message types
- Complete publisher/subscriber operations
- Proper validation
How will this change help?
- Provides a complete, real-world example of AsyncAPI's pub/sub pattern
- Helps new users understand how to structure event-driven APIs
- Shows proper validation and documentation practices
Screenshots
No response
How could it be implemented/designed?
Implementation Approach
- The AsyncAPI template will be implemented by centralizing all user-related events into a single userEvents channel. Instead of creating separate channels per action, this channel will act as the unified event stream for anything related to users. Each event published to this channel will be differentiated by its message type.
Three message types will be implemented on this channel:
UserSignedUp for new user creation
UserUpdated for profile or account changes
UserDeleted for account removal events
2)Each message will have a well-defined payload schema. During implementation, these schemas will enforce required fields, data types, and validation rules, ensuring that every published event follows a strict contract. This allows producers to fail fast if an invalid payload is sent and gives consumers confidence in the data they receive.
3)On the producer side, services will publish events using the publishUserEvent operation. Whenever a user action occurs (signup, update, or deletion), the service will emit the corresponding event to the userEvents channel using the appropriate message schema.
4)On the consumer side, downstream services will subscribe to the same userEvents channel using the subscribeToUserEvents operation. Consumers can then filter or route messages based on the event type (UserSignedUp, UserUpdated, or UserDeleted) and handle each case accordingly.
5)Documentation will be implemented directly within the AsyncAPI spec by adding clear titles, descriptions, and examples for channels, messages, and operations. Components will be organized so schemas and reusable definitions are easy to reference and extend as new user events are added in the future.
Finally, during implementation, YAML syntax issues and validation errors will be addressed to ensure the AsyncAPI file passes schema validation and works seamlessly with AsyncAPI tooling such as generators, validators, and documentation renderers.
🚧 Breaking changes
Yes
👀 Have you checked for similar open issues?
- I checked and didn't find a similar issue
🏢 Have you read the Contributing Guidelines?
- I have read the Contributing Guidelines
Are you willing to work on this issue?
None