Thanks Brian for your detailed explanation. Yes, I don't want to invent another FrontEnd for Jupyter Notebook.
I understand the separation effort <https://github.com/jupyter/enhancement-proposals/blob/master/jupyter-server/jupyter-server.md> 's motivation is targeting for writing / interacting with a new Jupyter frondend easily and gracefully, is that right ? My motivation is the resource optimization for the Jupyter Notebook user experience (just like Google Colab), that: - notebook viewing / editing is very rapid and lightweight, but might needs the plugins to work - notebook executing is resource consuming so the kernel would be started at this time Based on the structure "FrondEnd --> Backend -> Kernel", there are two approaches to achieve this: Approach 1: separate frondend and backend from "Jupyter Notebook" I guess the Google Colab just take this approach since that it could just work with my local "classic Jupyter Notebook" by the Rest/Websocket API. We don't want to follow this approach the main reason is we don't want to create another UI really. Approach 2: separate the kernel and backend deployment - a JupyterLab or classic Jupyter Notebook app process would be created for every notebook, assume this is some kind of lower resource consumption - a remote kernel would be launched only when execute the code in Notebook, the kernel management might leverage the Kernel Gateway / Enterprise 's work but this requires the Jupyer Notebook could be launched without kernel started, it looks like https://github.com/jupyter/notebook/issues/3170 is still under discussion. We would prefer approach 2. If I understand correclty, one of your suggestion is about trying to "deploying jupyter servers in separate containers + using the JupyterLab or classic notebook as it is". I understand this requires the modification in "JupyterLab or classic notebook" to delegate api request to the jupyter servers ? On Monday, April 29, 2019 at 11:55:55 PM UTC+8, ellisonbg wrote: > > What you are describing is possible, but there are a set of > constraints and trade-offs that may not give the experience you want. > Colab faces these same constraints and tradeoffs. > > * JupyterLab/classic Notebook have a range of different service APIs - > kernels, contents (file/dirs), terminals, kernel specs (kernel > metadata), etc. The standard way of operating Jupyter is to deploy all > of these services in the same server, and to also serve the frontend > JS/HTML/CSS from that same server. In the abstraction, the > architecture certainly allows you to deploy different services on > different servers. However in practice, it is probably not what you > want to do. The reason is that the different services have coupling > that directly relates to the overall usability: > > * Kernels and the file system are coupled, as a kernel needs to see > the same file system - to import other files sitting next to the > notebook, and to access co-located data files. So you can run the > kernel service separately, but it won't be useful for real work unless > you also figure out how to mount the same file system for that kernel. > * Terminals and the file system are coupled as users typically want to > see the real file system in the terminal. > * The frontend and kernels also have a coupling, because many kernel > libraries require frontend extensions to be installed. > > These are exactly the tradeoffs made by colab, and they severely > limits its usefulness for real work. But I do think these trade offs > do make sense for some usage cases. Right now, the code base isn't > optimized for this more decoupled usage case, but we have different > efforts moving in this direction. > > There is work to separate out the jupyter server and de coupled its > components here: > > https://github.com/jupyter/jupyter_server > > Unless I am misunderstanding your question, I don't think you are > looking to make changes to the frontend though - so I think the stock > JupyterLab or classic notebook would work fine. What you want is a > different way of factoring the server side of things. Probably the > most flexible way of refactoring the server would be to begin to use > the components of jupyter server, running in separate containers, > managed by something like docker compose with a traefik reverse proxy > in front. I would love to see explorations along these lines. > > I should also note that the Jupyter enterprise gateway might help in this > work: > > https://github.com/jupyter/kernel_gateway > > Hope this helps! > > On Sat, Apr 27, 2019 at 1:50 AM Song Liu <[email protected] <javascript:>> > wrote: > > > > Hi, > > > > Just like the Google Colab user experience, is that possible to separate > the JupyterLab Web and Backend ? > > > > That is the notebook viewing and editing functionality could be provided > by the JupyterLab web service just with minimum resource consumption. > > When running the Python code it could send it to a remote JupyterLab > backend (Server and Kernel). > > > > Thanks, > > Song > > > > -- > > You received this message because you are subscribed to the Google > Groups "Project Jupyter" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] <javascript:>. > > To post to this group, send email to [email protected] > <javascript:>. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/jupyter/d9872648-8909-4ad8-84f7-853ae8c81460%40googlegroups.com. > > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > Brian E. Granger > Associate Professor of Physics and Data Science > Cal Poly State University, San Luis Obispo > @ellisonbg on Twitter and GitHub > [email protected] <javascript:> and [email protected] <javascript:> > -- You received this message because you are subscribed to the Google Groups "Project Jupyter" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/bc426d56-9c7c-4620-92f3-a9b266b5e2e0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
