Skip to main content

Application lifecycle

As an example, from the point of view of user abcde1234, https://jupyterlab-abcde1234.mydomain.com/ is the fixed address of their private JupyterLab application. Going to https://jupyterlab-abcde1234.mydomain.com/ in a browser will:

  • show a starting screen with a countdown;
  • and when the application is loaded, the page will reload and show the application itself;
  • and subsequent loads will show the application immediately.

If the application is stopped, then a visit to https://jupyterlab-abcde1234.mydomain.com/ will repeat the process. The user will never leave https://jupyterlab-abcde1234.mydomain.com/. If the user visits https://jupyterlab-abcde1234.mydomain.com/some/path, they will also remain at https://jupyterlab-abcde1234.mydomain.com/some/path to ensure, for example, bookmarks to any in-application page work even if they need to start the application to view them.

The browser will only make GET requests during the start of an application. While potentially a small abuse of HTTP, it allows the straightfoward behaviour described: no HTML form or JavaScript is required to start an application (although JavaScript is used to show a countdown to the user and to check if an application has loaded), and the GET requests are idempotent.

The proxy however, has a more complex behaviour. On an incoming request from the browser for https://jupyterlab-abcde1234.mydomain.com/:

  • it will attempt to GET details of an application with the host jupyterlab-abcde1234 from an internal API of the main application;
  • if the GET returns a 404, it will make a PUT request to the main application that initiates creation of the Fargate task;
  • if the GET returns a 200, and the details contain a URL, the proxy will attempt to proxy the incoming request to it;
  • it does not treat errors connecting to a SPAWNING application as a true error: they are effectively swallowed.
  • if an application is returned from the GET as STOPPED, which happens on error, it will DELETE the application, and show an error to the user.

The proxy itself only responds to incoming requests from the browser, and has no long-lived tasks that go beyond one HTTP request or WebSockets connection. This ensures it can be horizontally scaled.