Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jupyter server vs Tornado Web Server in Jupyter Notebook #323

Closed
mwakaba2 opened this issue Oct 26, 2020 · 4 comments
Closed

Jupyter server vs Tornado Web Server in Jupyter Notebook #323

mwakaba2 opened this issue Oct 26, 2020 · 4 comments
Labels

Comments

@mwakaba2
Copy link
Member

Hi,

I'd like to learn more about the differences between the Jupyter server and the tornado web server in Jupyter notebook.
Could you elaborate the benefits for switching to the jupyter server?

For more context, my team and I maintain a Jupyterlab web application (version 1.2.x), and we're using the tornado webserver. We have a custom contents manager, and for performance improvements, we'd like to return Futures from the custom methods because they involve slow external API calls. We created a github issue in the jupyter/notebook repo: GenericCheckpointsMixin should consider Futures returned from contents manager?, and was wondering if there are benefits to switching to jupyter_server first and then requesting changes here instead. We're planning to upgrade to the latest Jupyterlab version.

@kevin-bates
Copy link
Member

Hi @mwakaba2,

Jupyter server is a Tornado Web Server that serves the REST API (and python classes) used by browser-based front-ends (and server-based extensions). It is essentially equivalent to the Jupyter Notebook server without the front-end. Jupyter Lab is intended to be the primary front-end but there is also an NBClassic extension to provide the look and feel of today's classic Notebook UI. In addition, I believe Lab is producing a "single-document mode" that also renders a trimmed down user experience - similar to what you'd find in Notebook.

The idea behind Jupyter Server is that it becomes the primary server and incorporates the necessary updates for improving performance and user experience in general. I would certainly include an update of the Contents Manager python API to be async-tolerant as one of those "necessary updates". We hold weekly team meetings and I think this would be a great topic for discussion.

Per the notice in Jupyter Notebook's README, we plan on transitioning focus to Jupyter Lab/Server while maintaining Notebook essentially at its current level of functionality.

@Zsailer
Copy link
Member

Zsailer commented Oct 27, 2020

Great question, @mwakaba2! Thank you for opening here. 😃

@kevin-bates great answer 👍 . Jupyter_server started as a fork of Jupyter Notebook's tornado web server, has evolved slightly to help ease the transition from Notebook-->Jupyter Server, and (hopefully) will continue to evolve as Jupyter's needs grow and evolve.

We're planning to upgrade to the latest Jupyterlab version.

JupyterLab's next release, 3.0 (currently in RC), depends entirely on Jupyter Server. This means, you'll want to submit your changes here if you want your feature reflected in JupyterLab moving forward. As Kevin mentioned, you can also run classic Jupyter Notebook on Jupyter Server using NBClassic.

@mwakaba2
Copy link
Member Author

@kevin-bates @Zsailer Thanks for the clarification! 🙂
I'll see if I can join one of the weekly meetings to discuss making Contents Manager python API async-tolerant.
Do you know roughly when 3.0 will be available?

@kevin-bates
Copy link
Member

Here's the issue tracking the Lab 3.0 release: jupyterlab/jupyterlab#8038. Looks like there are a couple of outstanding issues still remaining.

@mwakaba2 mwakaba2 closed this as completed Apr 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants