Long AsyncAPI document URL doesn't work

[helios2003]

Describe the bug

When we have a long AsyncAPI doc and if we try to share it via the copied URL it gives HTTP 414 Error code which translates to URI being too long.

How to Reproduce

• Open AsyncAPI studio and choose Kraken Websocket example.
• After the example is generated click on the Share link which generates the URL of the document.
• Paste this in the browser.
• It gives an HTTP 414 error.
• Screen recording

async-api-studio.mp4

Expected behavior

The document should be rendered as it is.

[helios2003]

If the maintainers think of this as an issue, I would like to work on it.

[KhudaDad414]

@helios2003 this was a known issue before implementing the share feature. The share feature doesn't work for long files. Is there a way to resolve this issue since it's a limitation by the "share" medium itself (i.e. URL)?

[helios2003]

Hi @KhudaDad414, from my knowledge whenever a document is shared the URL is uniquely identified through domain + some-id (of some fixed length) like in Google Docs. Is there any specific reason why the share feature was implemented as such?

[KhudaDad414]

The reason is that we are not storing anything on the server (like the services that you mentioned) so there is no way for us to read the document without passing the entire document in the URL.

[KhudaDad414]

One way that I think can help us solve this issue is compressing the file before converting it to BASE64 and when parsing, doing this but in reverse (convert from BASE64 and decompress) worth looking into.

[helios2003]

Even if we do that, a compression algorithm can only reduce the size by a certain percentage, and for huge documents, it might happen that the URL of the compressed document also exceeds the length limit specified. Also compressing and decompressing also will take some time (though they are rather quick). So won't this hurt user experience?

[KhudaDad414]

@helios2003 I don't think it's that resource-intensive. besides EVERYTHING on the web is compressed with gzip nowadays. and yeah, it just pushes it back a little. as I said. there is no way to solve this issue completely without having the file itself on the server.

[smoya]

Known issue as @KhudaDad414 mentioned. There was a proposal (just an idea of a project) I made time ago but for some reason is closed #127

@KhudaDad414 would you mind reopening it?

[Amzani]

@KhudaDad414 I guess migrating to NextJS will help us find a workaround on the server side.

[KhudaDad414]

@Amzani I guess so. Maybe we can use an ORM like Prisma connected to a local sqlite db. 🤔

@smoya what do you think?

[helios2003]

In the original issue where @smoya had mentioned a URL Shortener service. Should that not work just fine for this case? However, imho a quick hashing function might be better than a UUID.

[smoya]

@Amzani I guess so. Maybe we can use an ORM like Prisma connected to a local sqlite db.

@KhudaDad414 @Amzani That means you are gonna lose the state on each deploy.

In the original issue where @smoya had mentioned a URL Shortener service. Should that not work just fine for this case?

@helios2003 The URL shortener mention was just a nice to have. Just by using a URL shortener service doesn't solve anything since the URL shortener service will end up making a redirection to the full URL, meaning the same issue with long URLs will persist.

[smoya]

BTW, wrote a couple of lines with a new possible implementation for this in #127 (comment)

[Shurtu-gal]

@Amzani I guess so. Maybe we can use an ORM like Prisma connected to a local sqlite db. 🤔

By local sqlite do you mean in the deployment (netlify)

[smoya]

Please from now on write new comments regarding implementation details or questions in #127 (comment)

[aeworxet]

Bounty Issue's service comment

Text labels: bounty/2024-Q4, bounty/advanced, bounty/coding
First assignment to regular contributors: 2024-09-20 00:00:00 UTC+12:00
End Of Life after: 2024-10-31 23:59:59 UTC-12:00

@asyncapi/bounty_team

The Bounty Program is not a Mentorship Program. The accepted level of Bounty Program Participants is Middle/Senior.

Regular contributors should explain in meaningful words how they are going to approach the resolution process when expressing a desire to work on this Bounty Issue.

[Shurtu-gal]

Assigning to myself.

[aeworxet]

Bounty Issue's Timeline

Complexity Level	Assignment Date (by GitHub)	Start Date (by BP Rules)	End Date (by BP Rules)	Draft PR Submission	Final PR Merge Start	Final PR Merge End
Advanced	2024-09-16	2024-10-07	2024-12-01	2024-10-27	2024-11-17	2024-12-01

Please note that the dates given represent deadlines, not specific dates, so if the goal is reached sooner, it's better.

Keep in mind the responsibility for violations of the Timeline.

[aeworxet]

@Shurtu-gal is an AsyncAPI Maintainer specified in https://raw.githubusercontent.com/asyncapi/community/master/MAINTAINERS.yaml, so they fall under the first category in the prioritization list.

[Shurtu-gal]

@aeworxet This bounty issue can be considered as completed. Details are as follows:

Video Demo

out.mp4

Things done

1. As can be seen in the video currently sharing works through netlify blobs where each UUID is mapped to a document in the blob.
2. Instead of edge function we are using normal functions as npm-module support is still in beta and we don't want anything breaking 😉.
3. Still has the share as base64 in case people may not want to store it in our server due to privacy concern.
4. Added netlify config for easy deploy.

[aeworxet]

Bounty Issue Is Completed 🎉

@Shurtu-gal, please go to the AsyncAPI page on Open Collective and submit an invoice for USD 400.00 with the expense title Bounty studio#1030, tag bounty, and full URL of this Bounty Issue in the description.