Usage with `dask-labextension`

This is a follow-up with from some gitter chatting with @yuvipanda.

The dask-labextension JupyterLab extension currently involves adding iframe’d bokeh dashboard panels to the main work area. In order to get around CORS issues, it includes a modified version of nbserverproxy to proxy them under the notebook server origin. It is possible to do the same thing with an unmodified version of the package, but there were a couple of things that made me include the modified version:

1. I would like to leave open the possibility that the dashboard URL is not on localhost. Our current examples are all on localhost, but I don’t view that as a requirement that needs to be enforced, and we want to be able to support a wide variety of dask clusters which may have different deployment patterns that we haven’t necessarily thought of.
2. The dask labextension includes rest endpoints for cluster management as well as dashboard proxying. Currently, the cluster management endpoint is at /dask/clusters/<cluster-id>, and the corresponding dashboard is at /dask/dashboards/<cluster-id>. I’d like to be able to continue this pattern.

So there are two things that would be nice for nbserverproxy (or jupyter-server-proxy) to allow to be configured:

1. The ability to proxy to arbitrary URLs, rather than just ports on localhost.
2. The ability to place a given proxy at a different endpoint on the notebook server than /proxy/<port>/<path>.

I know that @yuvipanda has put some significant work into revamping this package recently, so it is possible that one can already do this. If that’s the case, do let me know!

[yuvipanda]

@ian-r-rose hold on for a day or two, and I think it’ll be clearer.

[mrocklin]

So, I’m also curious about this. Looking at the primary use cases listed in the readme I see the following:

Allow access from frontend javascript (in classic notebook or JupyterLab extensions) to access web APIs of other processes running locally in a safe manner. This is used by the JupyterLab extension for dask.

I think I’m curious now about what if the to-be-proxied server is living within the same process as the server, for example as part of a server extension. I can imagine using this with Dask, or also with other dashboards. For context today I’m working with @ian-r-rose on trying to make it easier to create dashboards with Bokeh and expose them through JupyterLab. My original thought was that the Bokeh server should just live within the same process as the Jupyter server living on the same event loop, rather than being a wholly separate process.