Use JupyterLite for try.jupyter.org

[jtpio]

Fixes #513

Opening this PR early for visibility and feedback.

Motivation

try-jupyter.mp4

The JupyterLab and Jupyter Notebook demo repos:

• https://github.com/ipython/ipython-in-depth
• https://github.com/jupyterlab/jupyterlab-demo

are quite popular and often reach the limit of concurrent users:

Plus mybinder.org is often the target of abuse usage, which unfortunately affects all members of the federations as well as uses. See #513 for more context.

This PR proposes to use JupyterLite for JupyterLab and Jupyter Notebook demos, with the hope this will reduce the load on https://mybinder.org and provide faster boot time so users can try the Jupyter interfaces quickly in their browsers.

TODO

• Update the links for the JupyterLab and Jupyter Notebook demos to point to a JupyterLite deployment
• Move https://github.com/jtpio/try-jupyter to https://github.com/jupyter/try-jupyter. Having a custom JupyterLite from https://github.com/jupyter/try-jupyter will make easier to maintain the deployment, pin dependencies and handle custom configuration
• Update the URLs to https://jupyter.org/try-jupyter (to not conflict with the existing https://jupyter.org/try
• Include a subset of notebooks from https://github.com/ipython/ipython-in-depth. Some IPython functionalities don't work in JupyterLite / Pyodide at the moment, and should not be part of the example notebooks
• Add a Tour of the interface(s) (Add a Tour of JupyterLite jupyterlite/jupyterlite#31), or a disclaimer this is a "lite" version of Jupyter and some functionalities might not work the same as in a "regular" Jupyter installation

Open questions

• For now RetroLab is used as the substitute for Jupyter Notebook, since Notebook v7 will be based on RetroLab. Maybe we should wait for at least the first v7 pre-releases before merging this? To reduce confusion among users who might not know what RetroLab is.
• How much traffic do we expect to have? How many users visit the https://jupyter.org/try page?

[choldgraf]

This looks great to me - the TODO list looks correct as well.

Responses to your two questions:

For now RetroLab is used as the substitute for Jupyter Notebook, since Notebook v7 will be based on RetroLab. Maybe we should wait for at least the first v7 pre-releases before merging this? To reduce confusion among users who might not know what RetroLab is.

Agreed - depending on the release plan for v7, maybe we just wait until it's out before we merge this PR?

How much traffic do we expect to have? How many users visit the jupyter.org/try page?

It's hard to say ever since we removed Google Analytics from the jupyter.org page :-/ - but looking at the logs, just before it was shut down, this page had about 70,000 hits a day. I believe that people who clicked one of the first two links made up about 25,000 sessions a day.

So now I'm worried we are going to hit data transfer limits very quickly if we're using GitHub pages to serve this :-/

[manics]

So now I'm worried we are going to hit data transfer limits very quickly if we're using GitHub pages to serve this :-/

You could host JupyterLite under a different GitHub account, so that if it does hit the GitHub pages limits it won't bring down the main jupyter.org site?

Any idea what the cloud charges would be for that amount of data transfer- could it be hosted on a static webserver running in one of the mybinder.org cloud accounts?

[jtpio]

Agreed - depending on the release plan for v7, maybe we just wait until it's out before we merge this PR?

There are a couple of blockers at the moment (jupyterlab/jupyterlab#11894 is one of them), and the pre-release plan is detailed in jupyter/notebook#6266.

At some point JupyterLite will update to JupyterLab 4 and Notebook v7 pre-releases, but it might still be a couple of weeks left before reaching that point.

So now I'm worried we are going to hit data transfer limits very quickly if we're using GitHub pages to serve this :-/
Any idea what the cloud charges would be for that amount of data transfer- could it be hosted on a static webserver running in one of the mybinder.org cloud accounts?

GitHub Pages have a soft limit 100GB / month: https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages#usage-limits

One way would be to put a CDN like Cloudflare in front of it. This will add some extra costs (maybe between $20 and $100 a month?), so still much less than what is needed for the k8s clusters.

[choldgraf]

Yeah a CDN seems reasonable for this purpose - if we got it working well then I think it would be a huge benefit to the Jupyter project, and would reduce a lot of load on mybinder.org. I'm sure we can scrounge up the funds.

I'm pretty sure that CloudFlare would have more than enough: https://community.cloudflare.com/t/cdn-bandwidth-limits/300965 (their pro plan is $20/mo https://www.cloudflare.com/plans/#overview)

[jtpio]

Move https://github.com/jtpio/try-jupyter to https://github.com/jupyter/try-jupyter. Having a custom JupyterLite from https://github.com/jupyter/try-jupyter will make easier to maintain the deployment, pin dependencies and handle custom configuration

In the meantime we can still make progress on the content for the JupyterLite website.

We can iterate on the repo directly: https://github.com/jtpio/try-jupyter. And optionally move it to https://github.com/jupyter/try-jupyter already so it becomes available at https://jupyter.org/try-jupyter (but without advertising it yet).

[choldgraf]

Note: Binder is out of credits again

I don't want to put undue pressure on this PR, but I wanted to note that gke.mybinder.org is once again out of credits jupyterhub/mybinder.org-deploy#2138). Is this PR in an MVP-like state where we could deploy it, in order to reduce some of the load on gke.mybinder.org?

[jtpio]

A first step would be to proceed to the move of the demo repo to https://github.com/jupyter/try-jupyter, and finalize the content.

Should we proceed with this first?

[manics]

I don't see any reasons not to, especially if Jupyter can pay for a CDN later if necessary.

[minrk]

move of the demo repo

That sounds good. We actually have a sponsored fastly setup for nbviewer, I think we can ask them if it's okay to use it for this, too. Or CloudFlare.

Some support for getting this done soon: now that we have upper limits on capacity, 90% of launch attempts at mybinder.org are being rejected during the busy part of the day. I believe the try jupyter links account for a large majority of this.

[jtpio]

move of the demo repo

Done: https://github.com/jupyter/try-jupyter

The demo site is available at: https://jupyter.org/try-jupyter

[choldgraf]

Given that Binder is already rejecting people at a fairly high rate anyway, I think that it's OK if we merged this in. Even if some behavior is unexpected or we uncover bugs, it feels like less of a problem since Binder will appear "broken" for people anyway.

(as an aside, I continue to have my mind blown by this project)

Proposal

What do you think about:

• Resolving the suggestions in this PR (mostly they are trying to set expectations for usres)
• Merging the PR
• As a follow up, figure out a CDN that increases our bandwidth.

?

[choldgraf]

Suggested change

	description: The original web application for creating and sharing computational documents
	description: The original web application for creating and sharing computational documents. ⚠️experimental⚠️this uses the <a href="https://jupyterlite.readthedocs.io/en/latest/">JupyterLite</a> package, please report any unexpected behavior.

[choldgraf]

If we think that the proposed "experimental" messages above are too much, I think we could also add an extra sentence to the introductory paragraph here:

Like

⚠️exprimental⚠️ several of the environments below use the [JupyterLite project](https://jupyterlite.readthedocs.io/en/latest/)
 to provide a self-contained Jupyter environment that runs on your computer. This is experimental
technology and may have some bugs, so please be patient and report any unexpected behavior.
Learn more about JupyterLife [at this link](https://jupyterlite.readthedocs.io/en/latest/).

[choldgraf]

Hmmm - putting that extra text in the card actually makes it really stick out vertically:

So how about we go with the "as part of the intro paragraph" option.

Here's a PR to try this: jtpio#1

[choldgraf]

Here's a preview of the relevant page: https://deploy-preview-682--jupyter-github-io.netlify.app/try

I think that we should merge this, for the following reasons:

1. These links are effectively broken now for a significant % of clicks, because of the limits on mybinder.org.
2. For that reason, it's at worst an even split if the JupyterLite links don't work as expected.
3. JupyterLite is more lightweight, much faster, and much more cost-effective than Binder, so we know we want to do this eventually anyway.
4. We have a big "experimental" warning on there, so hopefully we have set expectations accordingly.

I should also admit some conflict of interest right now, because 2i2c is currently footing the bill for gke.mybinder.org, and I have an interest in not spending as much money as possible :-)

[choldgraf]

@jtpio or @bollwyvl could either one of you give a 👍 that we can merge this? I feel hesitant to do so, given that it might generate a spike in attention to the jupyterlite repository. I wanna make sure that is a welcome action for y'all :-)

[bollwyvl]

Well, we were hoping to get a proper 0.1.0 release out now that (retro)lab had their latest releases out wednesday/today, but if it's time critical, and the content is already up, something based on 0.1.0b0 is as good as/better than any previous release. We have noted one minor regression on language packs, but only on our RTD setup, but I don't know if those are even installed on the new try site.

Regarding bandwidth: our biggest win, now that we've got deduplicated/cache busted things, our best "do less work" improvements would be:

• don't load numpy/matplotlib by default
• warm the serviceworker stuff back up
• improve the JS kernel experience
• look at bootstrapping off one or more of the browser-based p2p systems (e.g. IPFS, dat)

[choldgraf]

@bollwyvl do you think that any of those "to improve" items should block our merge here? I do think that this is a semi-urgent one, so IMO the reason to block would primarily be if it would create unpleasant experiences for the JupyterLite team. I'd be happy to delay merging this until, say, Monday (or a similarly near-term day) if y'all would like some time to clean something up.

[bollwyvl]

As a technology demonstrator still in beta, we've got a pretty tall backlog and quite a few contrbutors, but we don't really have a team per se... But I don't see any particular issues with broader distribution. Heck, maybe someone will be pissed Something Is Wrong On The Internet, and come help fix it.

[jtpio]

We have noted one minor regression on language packs, but only on our RTD setup, but I don't know if those are even installed on the new try site.

The language packs are available on https://jupyter.org/try-jupyter:

So probably just related to the demo site on RTD (https://jupyterlite.rtfd.io/en/latest/try/lab), which is tracked in jupyterlite/jupyterlite#529.

something based on 0.1.0b0 is as good as/better than any previous release

Yes, and once new jupyterlite releases are out, we can update the demo repo here: https://github.com/jupyter/try-jupyter/blob/7ad0578d47c5fae68679f28f1a9cc5dfac6babbc/requirements.txt#L12

do you think that any of those "to improve" items should block our merge here?

These will definitely take longer to implement and ship.

[jtpio]

As a follow up, figure out a CDN that increases our bandwidth.

We should already start thinking of a plan of actions for using a CDN, in case traffic is really high.

Another nice follow-up would be to add some privacy-friendly user tracking so we have a better idea of the number of folks reaching the demo site. Maybe also how long they stay on it.

[jtpio]

@choldgraf not sure if you had access to it, so I added you to the repo: https://github.com/jupyter/try-jupyter

Feel free to make any adjustment to the content. Maybe we could also add a quick section or disclaimer to the intro.ipynb notebook to indicate this is experimental?

[choldgraf]

OK, we've made a few PRs on the try-jupyter repository to improve the language and set expectations. I think that we are ready to merge this one in. I'll merge later today if nobody objects.

On the one hand, deploying on a weekend isn't a great idea. On the other hand, our setup is already broken, and if something really breaks in a bad way we will just revert the links on the website.

[choldgraf]

ok merged! let's all pray to the internet gods that we do not make them too unhappy