Uniform example with different use-cases

[jonaslagoni]

As the discussions become more and more complex I think it would make sense to uniform an example "system" to use as a reference for changes and suggestions.

I will suggest we use the example @fmvilas included in the proposal for solving publish/subscribe confusion.

This example takes into consideration of the different perspectives and use-cases we see AsyncAPI being used in. This does of course not mean any changes to the spec need to provide changes to this example, however, if it makes sense, people only need to know about one specific example to understand the changes that are being suggested, which I think makes it easier to understand the issue and the solutions proposed.

The proposed example

Say we have a social network, a very basic one, where all you can do is upvoting comments.

The individual services that need to be defined are:

• A frontend application where users interact through the website, where they can like comments.
• A backend WebSocket server that sends and receives events for the UI to update in real-time.
• A comment service which processes all events related to comments through a message broker.
• A public-facing API which allows others to get notified about updates.

This ensures that we try to describe:

• A public API
• A WebSocket server and client
• A broker setup

Suggestions

What do you think?

• Do you see this as being useful to have?
• Is there any changes to the system you would like to see?

Related resources

• chore: add social network example glee#174
• Proposal to solve publish/subscribe confusion #618
• The many meanings of an AsyncAPI file #628

[asyncapi-bot]

🎉 This issue has been resolved in version 2.3.0-2022-01-release.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[asyncapi-bot]

🎉 This issue has been resolved in version 2.3.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀