Share feature proposal

[smoya]

Reason/Context

The idea of this proposal is to add a "Share" button (or any component that fits) allowing the user to generate a URL that can be shared with anyone, and that will open the Studio but with the desired spec file loaded, representing that file in a certain moment in time, and loading any Studio setting the person who shared configured by then as well.

Sharing a URL that points to a reproducible Studio state is useful for several scenarios:

• Users can share AsycnAPI files without having to host them somewhere (like GH gists, etc), plus the fact you have all Studio amazing features out of the box.
• Tools that generate AsyncAPI files (like Chatbot, CLI...) could give a URL as a result instead of generating the code, or printing to stdout, etc.

You can see an example of such feature in Go (language) playground: https://play.golang.org/p/ENxYVMoY9VZ

Description

Let's see first a couple of mocks to illustrate the idea:

This is not as trivial as it might seem. I'm gonna add some context:

The first idea was to just accept all state (spec file, settings...) encoded as base64 in a query param. Then the studio will decode that value to obtain the state and draw it. The problem with this approach, as @magicmatatjahu stated, is that each browser have their own limitations on the URL length (also with the length of each query parameter). Most of them, limiting the full URL to 2048 chars which is not a lot. E.g. Streetlights MQTT example has ~6000 chars already.

With such limitation in place, there are not a lot of solutions for solving this.

Proposal

TL;DR: Storing the state in an external storage. Downloading it later and import it into the Studio.

[!IMPORTANT]
An alternative implementation, "cheapest" and simple-enough is mentioned in https://github.com/asyncapi/studio/issues/127#issuecomment-2074404179

• Generating the URL will require passing the current state (AsyncAPI file + any settings) to an external service, which will generate a UUID (either based on the content like SHA256, or a UUID v(x). To be defined) and store the given state in a Storage (external database, cloud storage, etc). That UUID will be returned to the Studio and will be the only identifier needed to construct the shareable URL. Optionally, to use (or maybe create our own?) a URL shortener service for making the URL shorter.
• Loading a shared URL will require a call to an external service (same), which from a given UUID, will fetch the state from a Storage (external database, cloud storage, etc) and return it to the Studio, which will load such state.

Note: Other services like Chatbot could also use this service.

Obviously, this is only the big picture. Details should be clarify. Further investigation should be done, especially around the following topics among others:

• What storage should we use? How can we get budget for it?
• Shall we use https://github.com/asyncapi/server-api as server for making the sharing logic? Or rather a separate microservice that just owns such responsibility?
• Security concerns. Only available to our services.
• Monitoring seems now like a must, as it is a server giving a functionality to a public hosted tool. High Availability is a must as well.
• Which protocol to use? GRPC?
• Etc.

cc @magicmatatjahu @derberg

[github-actions[bot]]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[aayushmau5]

Love this idea a lot. It would be interesting to see how we tackle these problems.

What storage should we use? How can we get budget for it? Shall we use https://github.com/asyncapi/server-api as server for making the sharing logic? Or rather a separate microservice that just owns such responsibility?

I have a feeling that we can go serverless for this approach(like cloudflare workers and cloudflare KV as a storage). Though we have to see the costing a bit, but I think it's really easy to get up and running with this approach.

[boyney123]

Yeah second what @aayushmau5 says, I like this idea @smoya. Sharing your state (doc) with others and other tools becomes very interesting.

I have a feeling that we can go serverless for this approach

Yeah guess loads of ideas we could go, but if you wanted you could go with a simple AWS Serverless solution that uses API Gateway + DyanmoDB (or s3) for example to store the data (even put a TTL on the data in the table so it expires/deletes after X days). Also, they offer quite a big free tier there. (Any hosting would work just need to figure out where as you said)

[derberg]

Great idea! From my point of view, the most important to remember is that Studio like Playgroud will be used by people on their own, behind their firewalls, in their own private clouds, or sometimes private access to public clouds like Google Cloud or MS Azure, in case of many corporations. So once we jump into implementation we need to, first of all, make sure people can easily disable Share button component, or enable it in an easy most vendor-neutral way possible.

[boyney123]

make sure people can easily disable Share button component

Yeah, I guess it would be good to identify a pattern in for feature flags in general. I imagine the studio will grow in the future with more and more features, so having a well-documented and easy-to-use feature system would be great.

[github-actions[bot]]

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

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 :heart:

[github-actions[bot]]

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

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 :heart:

[AceTheCreator]

@smoya how's it going with this?

Any help needed?

I resumed development on the chatbot and I could really use this feat.

[smoya]

@AceTheCreator AFAIK nobody is working on this feature yet.

[AceTheCreator]

@smoya no worries. I'll look into it and come up with something, then we can iterate from there. what do you think?

[smoya]

@smoya no worries. I'll look into it and come up with something, then we can iterate from there. what do you think?

Do you feel it falls into https://www.asyncapi.com/roadmap? If it does, I think you are free to pick it up (well we are always free to pick up whatever, but always convenient to follow the roadmap, right?).