daavidrgz
commented
1 week ago Maybe we should let the user decide the most appropriate expiration time of the sharable link. We can specify three values (1h, 1d, 1w) and pre-select in front the lowest value of them. This way, we encourage the user to save resources and only increase the expiration time when it's really needed. We can also implement a simple slider with more values.
Regarding the backend endpoint, maybe we should only limit the max expiration time that can be specified. It's true that anyone could make a custom request with arbitrary values, but I think this isn't a problem at all.
Concerning the limits on the input json/gq files or even the expiration time itself, I think that avoiding "duplicating" the validation in the back and the front leads to make an extra call to the backend to know what are those limits and I think that it doesn't offer enough benefits.
jorgehermo9
We should support shareable links in the playground
There are currently two valid approaches
Maybe we should the user choose between those options, whichever fits them better?
Another option would be that the frontend tries to encode the state in a base64, and if the length is greater than 2000 characters, then the link is stored in the backend. We should warn the user when this happens and notice them of the retention period of that state (the backend should expose the configured retention time so the frontend can dynamically query it)