I’m attempting to use a Pouchdb-server instance behind Jupyter_server_proxy to communicated state between my frontend JS app, Jupyter notebook, and Bokeh app. Installing and running the server was a breeze, but now I have a problem: what’s the URL of the server?
At a later stage I would also like my Bokeh app to talk to the Jupyter server REST API.
In the frontend JS I can obviously just derive the database URL from window.location but on the backend it’s not clear how I would find out where the database/Jupyter server lives.
How do I find out the URL of the binder instance from Python?
Hi! which “server” are you talking about? The jupyter-server, or your pouchdb-server? Where does the connection originate from- the frontend JS, or a backend component? Is everything running in the same container, or do you have a custom BinderHub deployment with additional services running separately?
Jupyter server runs the proxy which launches pouchdb on a random port. So to access pouchdb at this random port I need to go through Jupyter. Of course for accessing the Jupyter API I need to go to Jupyter anyway.
As a hack I can set a fixed port and access Pouchdb directly, but that doesn’t solve the more general problem of getting the URL for Jupyter.
This is all standard Jupyter stuff running on standard binder, same container.
The connection originates from everywhere because I use PouchDB to tie together a pure JS client side app, Jupyter notebooks, and a Bokeh app. So I need to access the database both from the frontend and backend.
Somewhere down the road I want the Bokeh app to create new notebooks in Jupyter so that’s going to be another case where Bokeh needs to find out how to talk to Jupyter.
I recommend creating a predictable endpoint rather than relying on the random port.
Inside the server (or a kernel, or any other process started by the server), you should find the path in an environment variable JUPYTERHUB_SERVICE_PREFIX.
Generally, there’s no way for a server to know where the client is actually resolving, as it is behind many layers of proxies. As long your application is ready to handle a configurable base url and port, e.g. not just :8888/, it should all work.