In the docs section discussing deployment, there are examples to which I have contributed, regarding reverse proxying with both nginx and Apache.
As things stand currently, bokeh static resources are always accessed by the browser on the /static path. It is then advised to let the web server handle requests for these files by aliasing the /static to wherever the bokeh/server/static directory happens to be on disk.
This is fine if your apps share the same bokeh version and thus the same expected bokeh/server/static files. But this approach breaks down if they don’t. This means that whenever you update your bokeh version for one app which is deployed on a server with other apps behind the same reverse proxy, you have to ensure the compatibility of all apps with the new version of bokeh and update their environment too. In a situation where multiple developpers work on apps hosted together, this will soon get wildly unpractical.
To my knowledge the only way to solve this issue is with a pretty unorthodox use of prefixes, since static resources will then be accessible at http://host/prefix/static, which can point to different locations depending on the app. Then you could either let bokeh serve them (suboptimal) or add multiple aliases in your web server configuration.
This is rather convoluted though. My understanding is that the request path to static files is pretty fundamental to how bokeh server works. For example one could not imagine that these resources could be served at /app/static instead (this would actually lead to conflicts with a potential directory named static in the app directory). But maybe other options could be discussed?
Hi @Theom I expect there is some way to make this work, but I also have to state that AFAIK you are the first person to want to try, so I don’t have any specific advice I can give (I am not an apache or nginx expert and what is already in the users guide is more or less my sum total of knowledge).
I might suggest a different simpler approach though. Bokeh server uses its own static resources by default, but you can configure BOKEH_RESOURES=cdn and then it will load (an appropriate version of) BokehJS from cdn.bokeh.org instead. This will free up your proxy from having to serve these files altogether, and will also be better locally cacheable by browsers. Note that this change requires the viewers of the app to able to access cdn.bokeh.org so it would not be an option on an airgapped or restricted network
Here is how a BokehJS load looks like on my laptop on my network, but how things perform for you depends on your your setup, I have no way to predict that.
I think that is something you will have to run the experiment with so see how it performs under your specific expected circumstances, and whether the results meet your particular needs. FWIW BokehJS is served from an AWS S3-backed Cloudfront CDN.
