User is able to focus only on business logic

[fmvilas]

Description

Ideally, the user should not be focusing on anything that's not related to their business logic. This includes learning the AsyncAPI specification. Nobody should be forced to learn the AsyncAPI spec to create a basic API. However, it doesn't mean the user should not be able to improve or create more complex APIs if they learn AsyncAPI and its tooling.

Scope

1. An AsyncAPI file can be created without having to understand AsyncAPI syntax. This can be a CLI tool that asks questions, an application UI, a form, etc.
2. Custom logic can be triggered when a message is received on a channel.
3. Custom logic that sends a message can be triggered as the result of receiving a message, on startup, or any other application lifecycle event.
4. Data models must be handled automatically, meaning the user doesn't have to manually create them.
5. Sent and received messages must be validated against an AsyncAPI document.
6. Works with the main protocols: HTTP, WebSockets, Kafka, AMQP 0-9-1, AMQP 1.0, MQTT, and MQTT5.
7. Works with all the supported security schemes.
8. The result is production-ready.

[boyney123]

Love the ideas here @fmvilas

The scope seems quite big, but I'm gonna spike some ideas around :

An AsyncAPI file can be created without having to understand AsyncAPI syntax. This can be a CLI tool that asks questions, an application UI, a form, etc.

Gonna see how it looks/feels creating the spec from a UI/Component, my thoughts are using some kind of UI to create events and servers etc etc link them up and generate the file....

Will ping some mockups/spikes here for community feedback before going deep on it :)