Temporarily use JupyterLite for high-traffic links to mybinder.org

[minrk]

The first couple of links on https://jupyter.org/try drive a huge amount of the overall traffic on mybinder.org. We're currently dealing with a bit of a funding crisis, so we might try shifting the highest traffic links to JupyterLite demos, instead, to reduce the gap funding we need to cover while we figure this out.

Maybe someday JupyterLite will be in a place where this is the right thing to do in the long term, but probably now wouldn't be the time if we don't need it. This isn't ideal, but the alternative would be for the links to just stop working, which seems worse. Plus, an exciting demo for Jupyter Lite!

[bollwyvl]

I actually have some days off coming up, so if we have to spike this, I can support it. I think everything's working basically as well as it ever has at this point, even though we're still in alpha, nominally.

It's really just a matter of what we want:

• content
• extra experiences (e.g. tour)
• build chain (e.g. straight lite, sphnx)
• host (e.g. RTD, gh-pages... I've some success with gitlab

If we need some more bespoke labextensions, that's also very doable.

At present, there is no google analytics or anything: probably doable.

[choldgraf]

@bollwyvl what do you think is the biggest bottleneck that we would need to worry about, if there were a large spike in people clicking a link that served a JupyterLite?

[SylvainCorlay]

I will see if we can help with that.

[bollwyvl]

biggest bottleneck

There aren't any, really. Once deployed, provided the host (whatever it is) has a CDN in front of it, it can be entirely self-sufficient and cached (just GET requests), including mathjax, pyodide, and whatever PyPI wheels we might want to pre-load, with the fallback to "big pypi" (which is also behind a CDN).

[choldgraf]

I would am definitely in favor of this, provided that the JupyterLite team is confident that this wouldn't generate a lot of negative attention their way once a lot more people were clicking those links. For generic and straightforward Jupyter experiences, like the ones that try.jupyter.org is meant to serve, I think JupyterLite is a much better solution than a full-blown image setup like mybinder.org . It would save cloud spend for the Binder team, and I think would provide a nice more lightweight solution to complement repo2docker.

[bollwyvl]

negative attention

Yeah, there are a number of known issues that are going to be surprising to people, but yeah, in this case, it's a demo.

Some gotchas:

• all over
  • no terminals (we need busybox or something)
  • the caching doesn't always work the way we'd hope
    • Add offline support jupyterlite/jupyterlite#137 would be a HUGE step, but we haven't looked at it in some time
• in lab
  • you really can't have more than one or two kernels running
• in retro
  • the urls won't be exactly like one remembers
• in pyodide
  • a fair amount of stdlib is missing (what the hell is a process?)
  • no requests.get (gotta use js.fetch)
  • gotta await piplite.install everything before using it

[choldgraf]

Just to put some back-of-the-hand numbers to this, I grabbed the latest 30 days of activity on mybinder.org from @betatim's binderlytics analyzer.

For the top 20 repositories (that make up about 75% of Binder traffic). If we split those repositories into ones that are served by try.jupyter.org, and all the rest, we get something like this:

About 600,000 are from try.jupyter.org, and about 120,000 are from other repositories. This means that if we were serving try.jupyter.org via jupyterlite, it would reduce mybinder.org's launch load by more than 50%, which would save a lot of resources.

That said, from a CDN standpoint, could JupyterLite be realistically served to users 600,000 / 30 = 20,000 times a day? I don't know as much about the size/complexity/etc, just making sure that we wouldn't hit an unexpected order-of-magnitude problem

[bollwyvl]

From a cold start, the jupyterlite launcher page is (gzipped) 3.1mb vs 1.8mb for the jupyter.org home page, all fronted by cloudflare. At that point, it's already got, a lot of features like markdown rendering, but doesn't yet have mathjax or any kernels.

By the time the baseline pyodide notebook loads with a pyolite kernel, it's up to 31.5mb, with almost all of that coming from pyodide on jsdelivr... but at that point has already loaded matplotlib, numpy and a lot of other stuff. Meanwhile, the /widgets page is 14.9mb.

So a "bounced" lite load is ~2x home page loads, "full" interactive lite load is ~10x home page loads, and ~2x widget page loads, which seems like it's not going to break anything too badly.

I've also been toying with shifting some of the heavy to p2p tech... we could likely fit the relevant parts of lab, retro, and the demo wheels within the free tier of many of the IPFS pinning services, and then cloudflare would also host that.

[choldgraf]

Just read your response and want to note how cool jupyterlite is lol

[bollwyvl]

Note, of course, of try.jupyter.org's hero badges, we'll only be able to support lab and python directly, and retro as a stand-in for classic.

There are a few other kernels ready to go (p5, lua, wren), a few on deck (robotframework) but r, julia, kotlin, scheme, ruby, voila, are not happening by next week.

[choldgraf]

I don't think that'd be a huge issue for now. by far the most common repositories are:

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

ipython in depth has no non-Python code, and is the most heavily used
the jupyterlab demo does have non-python stuff (it is kind of a "jack of all trades" repository. But in my opinion, we'd be fine collapsing that to just Python for this particular try.jupyter.org link, and adding another repository / demo that included the non-python stuff

[choldgraf]

Proposal

Since we are not sure exactly what will happen once we turn on the floodgates of people clicking Jupyter Lite links instead of mybinder.org links, what if we did the following:

• Created a JupyterLite demo (maybe the one that's currently at the Jupyter Lite docs?) that was a lightweight introduction to Jupyter Lab. It would also discuss what Jupyter Lite is, and explain that it was a lightweight Jupyter Lab environment.
• bumped the current Jupyter Lab demo to the second row so that it has a bit less visibility.

This would slightly reduce the load on Binder, and might be a way for us to identify any issues that popped up in Jupyter Lite as a result. All the old Binder links would still be there, just wouldn't be the first two options on the page. Then after a few weeks if all is well, we could swap the other link (ipython in depth) or do the same "bump to below" approach described above.

Reasoning: Those try.jupyter.org buttons are for people who are learning about Jupyter for the first time. They don't need to be "in-depth" style tutorials - those are better designed for somebody that already knows about Jupyter and has the time/energy to dive in further, so it's OK if it takes more searching for them to find those tutorials. Better to keep the "above the fold" buttons to go towards quick, lightweight, "I have 30 seconds of attention span" experiences, that then direct users to another space if they want to learn further (like a full-blown Binder tutorial).

[choldgraf]

I made a short PR to JupyterLite to add what I think are some minimal "getting started" notebooks to the JupyterLite documentation, so that we can feel more comfortable sending first-time users there if we want to use try.jupyter.org for this: jupyterlite/jupyterlite#432

If folks are generally OK with this plan, how about we try adding the following link as the second button on try.jupyter.org, and bumping the current JupyterLab button below the fold.

• https://jupyterlite.readthedocs.io/en/latest/_static/lab/index.html?path=intro.ipynb (won't work until the PR above is merged and deployed to the docs)

If this works out, we can do a similar thing with the IPython link as well: