Skip to main content

Infrastructure Architecture

JHub Apps, also known as JupyterHub Apps Launcher, is an Externally-Managed JupyterHub service designed to enable users to launch various server types including API services, dashboards such as Panel, Bokeh, Streamlit, standard JupyterLab instances, and any generic Python command.

The system is built on a FastAPI framework as detailed in the services.apps module. It initializes and runs through a Uvicorn server (a WSGI HTTP server), managed by the JupyterHub service manager upon startup:

jhub_apps/configuration.py#L42-L5
c.JupyterHub.services.extend(
    [
        {
            "name": fast_api_service_name,
            "url": f"http://{c.JAppsConfig.hub_host}:10202",
            "command": [
                c.JAppsConfig.python_exec,
                "-m",
                "uvicorn",
                "jhub_apps.service.app:app",
                "--port=10202",
                "--host=0.0.0.0",
                f"--workers={c.JAppsConfig.service_workers}",
            ],
            ...
        }
    ]
)

This service operates on the Hub's host at port 10202, with a set number of workers as specified in the service_workers configuration parameter. It is accessible to users through the Hub's proxy, which directs requests to this service URL.

JupyterHub comprises four primary subsystems:

  • a Hub (tornado process) that serves as the core of JupyterHub,
  • a configurable http proxy (node-http-proxy) that routes incoming browser requests,
  • multiple single-user Jupyter notebook servers (Python/IPython/tornado) managed by Spawners,
  • and an authentication module that governs user access.

Upon its launch, Jhub-apps is integrated into JupyterHub as a new service. This addition modifies the Hub's homepage to feature the service's URL, thereby offering users not only access to other services but also control over spawning different frameworks beyond JupyterLab, like Streamlit and Bokeh, while utilizing JupyterHub's authentication and spawner mechanisms.

The newly added Jhub-apps service introduces intermediate steps that tailor request routing based on the selected framework:

  • The Hub initiates a proxy,
  • Jhub-apps is launched and registered with JupyterHub,
  • The proxy initially routes all requests to the Hub,
  • Jhub-apps modifies the Hub's homepage to include its URL, extending the service selection options for users, who can now choose from a variety of frameworks.
  • The Hub continues to handle logins and server spawning,
  • Jhub-apps adjusts the request handling to direct users to the appropriate single-user server environments based on their selections.

Below is a diagram illustrating the technical architecture of the JHub Apps service and its interaction with the JupyterHub system:

Technical Architecture Diagram​

JHub Apps Architecture

Starting from the left of the diagram:

  • users engage with the JupyterHub interface via their browsers, logging in through their preferred OAuth providers (e.g., GitHub, Google). Authenticated users are redirected to JHub's homepage, where they select and launch the desired service.
  • As an external server managed by JHub, the JHub Apps service maintains full access to JupyterHub’s authentication, authorization, and access controls. As a results, users still maintain the capability to visit Hub's buil-in pages.
  • On the homepage, users can choose the specific framework to deploy as a single-user server. JHub Apps then spawns the selected framework similarly to how JupyterLab is launched. The service redirects users to their individual server instances, where they can interact with the chosen framework.

Looking Under the Hood​

Proxies within JupyterHub act as gatekeepers, dynamically updating internal routing to direct traffic efficiently and securely to the appropriate server instance. This setup not only supports default proxies but also allows for custom proxy configurations to manage various external applications seamlessly.

Jhub-apps introduces an additional layer of proxy management for custom frameworks, employing the jhub-single-native to replace the standard jupyter-singleuser with any web service directly.

Spawners are one of our major focal points in JupyterHub, acting as abstract interfaces to processes. They can start, monitor, and stop single-user servers, and are responsible for managing the lifecycle of the user's server. Jhub-apps extends this functionality to support a variety of frameworks, enabling users to launch different server types beyond JupyterLab.

When a user selescts a framework, JHub Apps balances the given requests into to possible proxies, each one corresponding to a different framework type. For conventional jupyterlab instances, the request is directed to the standard jupyter-singleuser proxy. For other frameworks, the request is routed to the jhub-single-native proxy, which handles the request and launches the appropriate server instance.

Bellow we can see another diagram that illustrates the interaction between the two proxies, in a kubernetes environment:

JHub Apps Proxy Interaction