Add start studio command

[magicmatatjahu]

In asyncapi/studio#80 has been proposed to add the start studio command, which:

• should start local instance of our Studio (first we have to implement it)
• should start local instance of API - Create (server) API for Studio studio#86
• should run a simple server that would support the filesystem to be able to read/write content from/to files

For example, a user could use this command to edit an AsyncAPI document in their favorite IDE, but could also see immediatelly changes in the rendered html-template. The local server would see the changes in the AsyncAPI document - including references to local files - and then pass such a file to the Studio, where the user could use UI to do necessary things like model generation, optimizations, check for changes between versions, etc.

[derberg]

we should definitely make sure to drop a message that started server should not be used on production 😄

[magicmatatjahu]

Right, but I understand that from the concept of the command 😄

[fmvilas]

I was going to create another issue related to this but instead, I'm gonna reuse this one. I did a quick PoC on my machine with the asyncapi new command:

Code.-.Studio.ts.cli.-.27.October.2021.mp4

I'll now extend it to asyncapi start studio.

we should definitely make sure to drop a message that started server should not be used on production 😄

The server is not started on Studio but on the CLI. Studio just runs a WebSocket client :)

[magicmatatjahu]

The server is not started on Studio but on the CLI. Studio just runs a WebSocket client :)

Łukasz had in mind server-api to have local version of server to enable generation of templates etc, so as not to overload the server at api.asyncapi.com :)

[fmvilas]

Oh yeah, definitely 👍

[smoya]

From Slack, complementing what @fmvilas suggested, I think we could also go further and enable collaboratively editing of AsyncAPI Files through the Studio, meaning some users could be editing the same file in real time.

Not sure if this is a very interesting feature or not, but just in case I drop here a chart I wrote explaining how we could achieve that in top of @fmvilas idea.

TL;DR: Use Localtunnel, a node package that exposes your localhost to anyone, giving you a public URL. This will expose the CLI WS server to any other remote Studio app.

Note that even though the service is hosted by them (loca.lt Is the domain they give to all tunnels), the proxy server is available and can be deployed to our own premises and use our DNS as well, so domains could look like <random-id>-studio.asyncapi.io. But this is something that I would not go for at least by now because it implies maintaining the service ourselves :).

[fmvilas]

@smoya This looks super. I'd create a separate issue, otherwise, we risk not looking into this anymore after this issue is solved.

Note that even though the service is hosted by them (loca.lt Is the domain they give to all tunnels), the proxy server is available and can be deployed to our own premises and use our DNS as well, so domains could look like -studio.asyncapi.io. But this is something that I would not go for at least by now because it implies maintaining the service ourselves :).

If we ever deploy our own WebSocket server, we would not need the server on the CLI then. The CLI would be just another WS client, like the one on Studio, both connected to our production server. It would be interesting to see something like this deployed 😄

[smoya]

@smoya This looks super. I'd create a separate issue, otherwise, we risk not looking into this anymore after this issue is solved.

Note that even though the service is hosted by them (loca.lt Is the domain they give to all tunnels), the proxy server is available and can be deployed to our own premises and use our DNS as well, so domains could look like -studio.asyncapi.io. But this is something that I would not go for at least by now because it implies maintaining the service ourselves :).

If we ever deploy our own WebSocket server, we would not need the server on the CLI then. The CLI would be just another WS client, like the one on Studio, both connected to our production server. It would be interesting to see something like this deployed 😄

Not sure if it is ideal to force users to go always through our hosted server. This means people won't be able to edit offline, for example. Also to not overload the server unnecessary (same as for the api-server. See #78 (comment))

Anyway, I created a new issue so any discussion regarding that should be moved there: #104

[fmvilas]

I'm closing this issue as it's already implemented in #102