Implement a fps plugin for Voila

[jtpio]

Problem

In the Jupyter Server Meeting yesterday, we discussed the use case of having a fps plugin for Voila. This would be a good example for having a tihrd-party plugin living in a different repo.

fps and jupyverse are still experimental projects, but since jupyverse relies on entry_points to load the plugins, we could imagine having the fps-voila plugin as part of the voila package already.

This could be shipped as an early preview and released as part of the 0.3.x series.

It would also help refactor the voila logic so it can be used with both jupyter_server extensions and jupverse plugins.

Proposed Solution

We add a fps-voila plugin some time in the 0.3.0 release (additive change).

Additional context

• Towards a new generic and composable server jupyter-server/team-compass#11
• https://github.com/jupyter-server/fps
• https://github.com/jupyter-server/jupyverse

[davidbrochart]

I am implementing a fps-voila plugin, and I wanted to share some thoughts about the difficulties I am encountering:

• Voila is tightly coupled with Tornado's API. In particular, for progressive rendering, Voila sends parts of the HTML. This seems hard to do with FastAPI.
• Voila is a configurable application. It creates the Tornado handlers when it is initialized, meaning the endpoints themselves could depend on configuration. But FPS's plugin system requires that endpoints are known at import-time, which occurs before Voila is configured.
• Voila is tightly coupled with nbclient for the notebook execution, which in turn is tightly coupled with jupyter_client's kernel managers and clients. Reusing fps-kernels requires wrapping a KernelServer so that it's accessible through jupyter_client's API.

[SylvainCorlay]

Voila is tightly coupled with Tornado's API. In particular, for progressive rendering, Voila sends parts of the HTML. This seems hard to do with FastAPI.

Maybe @maartenbreddels has a clue on how other frameworks than tornado enable partial responses to HTTP requests.

Voila is tightly coupled with nbclient for the notebook execution, which in turn is tightly coupled with jupyter_client's kernel managers and clients. Reusing fps-kernels requires wrapping a KernelServer so that it's accessible through jupyter_client's API.

I am not sure this is really an issue since the notebook execution through the executor is independent from the fps-kernels thingy.

[trungleduc]

• Voila is tightly coupled with Tornado's API. In particular, for progressive rendering, Voila sends parts of the HTML. This seems hard to do with FastAPI.

StreamingResponse from starlette might help? It's also available in fastapi (https://github.com/tiangolo/fastapi/blob/master/fastapi/responses.py#L9)

[davidbrochart]

Indeed, thanks @trungleduc !

[davidbrochart]

I am not sure this is really an issue since the notebook execution through the executor is independent from the fps-kernels thingy.

You are right, we can keep the jupyter_client kernel management in the backend, and use the kernel's connection information in KernelServer which talks to the frontend.