Question about the status of jupyter server for extensions (headless notebook)

Hello to all,

I am trying to handle an issue I currently have at work, and I think you might provide me with some useful insight.

I am currently developing rather complex UIs for statisticians. I have routines in R or python to invoke. I want to use React for the frontend, due to the large amount of libraries available for additional needs I have.

My first idea was of course to have a simple flask application that provides a REST api to invoke the python or R code. However, this is not so simple. The typical workflow is that the user uploads files, performs subsequent invocations of various statistical operations, possibly time consuming, possibly getting some plots as results, and steering the evaluation along the way. So I need to preserve state of the evaluation, kind of like a kernel does.

I also do not want to have a solution relying on websockets. The user must be able to disconnect and reconnect later without having problems. While there are solutions to this, I don’t think they are useful if I take another approach.

My idea was to use jupyter to start a kernel, which is long lived, and submit REST/RPC requests to it with the React frontend. Sort of like a “headless notebook” with a purely REST/RPC interface, giving me control of the frontend development and handling the session and state management to the kernel.

I am not aware of any solution for this, so I was thinking about implementing it myself. My questions are:

  1. Am I wrong? does something like this exist already?
  2. If not, I am examining both notebook and jupyter_server. It seems to me that there’s some overlap between them, and I suspect jupyter server is being extracted as an independent component from notebook. Is it correct, and if so, what is the state of this extraction?

Thank you.

1 Like