jupyterlite / repo2jupyterlite

Build jupyterlite apps out of repositories
BSD 3-Clause "New" or "Revised" License
27 stars 4 forks source link

URL Design plan #7

Open yuvipanda opened 1 year ago

yuvipanda commented 1 year ago

Braindump + plan from the plane!

  1. Users should be able to copy paste the URL they are in and share it with someone else. This should "just work" - unlike how things now go with mybinder.org.
  2. No state must be maintained anywhere.
  3. Is perfectly ok to have some build redirects in there to show people proper UI when we need to do a build. We aren't trying to trigger rebuilds for requests to JS, for example.

State required for building is:

  1. repo provider
  2. repo slug
  3. ref slug

so a URL structure could be like:

/v1/<repo-provider>/<repo-slug>/<optional-ref>/

So if we get a request for

/v1/gh/yuvipanda/environment.yml/rel/index.html

we parse this out first into:

repo_provider = gh repo = yuvipanda/environment.yml ref = rel file_path = index.html

And we check if the repoprovider, repo, ref exists. If it does, we then _manually proxy (not redirect) to the source file. This adds additional complexity - we act as a somewhat inefficient proxy. However, that is the only way to give the user the experience of being able to copy paste what they see in their URL bar and 'just' have it work. That is a very important UX affordance we must offer to people.

  1. request comes in
  2. We parse the parts out
  3. Check if it has been built
  4. If it has been built, we proxy out the appropriate files.
  5. If it has not been built, we redirect to a build UI.

So simple staticfiles won't be enough.