Integration of AsyncAPI CLI with studio.asyncapi.com via WebSocket/HTTP Server

[KhudaDad414]

Current Approach:

The current implementation of AsyncAPI Studio involves publishing it as a React application (which is broken right now) on npm. The AsyncAPI CLI then installs this as a dependency and spins up a local instance of the Studio to edit AsyncAPI files.

Proposed Change:

After some discussions with @Souvikns we propose a more integrated approach where the AsyncAPI CLI establishes a WebSocket/HTTP server. Instead of running a local server for the Studio, studio.asyncapi.com would interact directly with the CLI via a WebSocket/HTTP connection. This connection facilitates two-way communication:

• The CLI sends the AsyncAPI file to studio.asyncapi.com for editing.
• studio.asyncapi.com uses the WebSocket link to publish changes back to the CLI, which makes these changes into the local AsyncAPI file.

Arguments For This Approach:

1. Reduced CLI Size: Bypassing the need to package Studio with the CLI significantly reduces its file size. Users will always have access to the latest version of Studio without requiring updates to the CLI.
2. Improved Integration and Communication: This setup opens up possibilities for deeper integration, like adding a feature in Studio to initiate Glee project generation commands that are executed by the CLI.
3. Local Processing: All interactions occur locally on the user's machine, so privacy of user's data is kept.

Arguments Against This Approach:

1. Internet Requirement: Users will need an active internet connection to access studio.asyncapi.com.
   (Please tell me...)

Additional Considerations:

• Security: Letting others run commands, access data, with this kind of interface would be a little risky for user. (maybe CLI should only accept requests from it's local environment. 🤔 )
• Error Handling: Not sure if this approach is stable enough for pushing the changes to cli.

Technical Details:

• CLI Changes: The CLI will feature a new WebSocket or HTTP interface, documented with AsyncAPI, providing functionalities like serving the AsyncAPI document, accepting published changes, and executing CLI commands.
• Studio Modifications: Studio will connect to the CLI using the mentioned interface, allowing it to perform required operations seamlessly. through some like like: https://studio.asyncapi.com/?cli-url=ws://localhost:3000/cli-server

cc: @fmvilas @derberg @jonaslagoni would love to have your input. 🙇

[Amzani]

@KhudaDad414 If we find a way to always have the latest working version running locally, would that solve the issue? I'm not sure about the security/internet requirement trade-off.

I also see a shift toward using IDE extensions - so people might just use VSCode + vs-asyncapi-preview to render docs, it doesn't provide the full studio experience but the majority of users are probably using studio only for that, this is why we need some insights asyncapi/studio#858

If we really want to push for that, then having a choice can work, and users can choose which instance of studio they want to run local or remote.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[KhudaDad414]

closing this issue since the local Studio is working fine with cli for now.