That's great to hear. Since a few people have expressed interest in a couple of different variants of these ideas, I thought I would lay out the different cases (as I see them) so that work can be planned with full information.
The general problem statement "add new apps dynamically". There are two approaches to this:
The latter is more along what Mime suggested in the other reply. I think this is an interesting and useful thing, but also out of scope for the core project. So I will try to outline some different possibilities for "Allow a running bokeh server to add new apps" which I do think is in scope, and which might be useful for many simpler use cases. I think it's worth discussing what the actual best approach might be first, then I can point to specifics in the repo and docs for making changes.
···
==========
"Config File" approach
----------------------
Currently apps are specified on the command line at startup:
bokeh server app1 app2 ...
One possibility that has been mentioned is to allow Bokeh server to take its app configuration from some sort of YaML/JSON/whatever config file, instead of just the command line. I think this is a fairly simple and straightforward task for someone with moderate Python experience, and could be done as a small initial PR. Once this is done, the next step would be to add a way for the Bokeh server to re-read the config file, and update the installed apps based on the new contents. There are a couple of possibilities:
* Make Bokeh server re-read the config file when it gets a HUP signal, i.e. "kill -15 <server pid>" would cause the server to reload the config. This is definitely a well known pattern on Unix-like systems. I'm not sure if something similar exists on Windows. If not, this approach is probably not a good one.
* Make Bokeh server monitor the file for changes. This could be accomplished either with explicit polling in some kind of periodic callback, or by using something like the "watchdog" project in a separate thread, and sending some async signal to the bokeh server to "reload" when a change happens. The latter is probably more efficient and performant, but also probably a bit more work.
There are issues to consider with this overall approach. I.e., if running multiple bokeh servers behind a load balancer, for instance, they all need to update. That probably points to the second approach as more reasonable.
Also neither of these touch on the "reload a page for a changed app" case that some user's have asked about. (i.e. the "Flask debug mode" analogue). That would require some BokehJS work and I think is out of scope for this discussion (and would not be an appropriate mode for "production" use in any case).
"On Demand" approach
--------------------
Another idea, which similar to one part of Mike's orchestration idea, is to have Bokeh simply try to look for the appropriate file or directory whenever and unknown URL comes in, i.e. an end user navigates to the URL
https://foo.com/some_app
And there is no "some_app" loaded, Bokeh could look for an appropriate "some_app.py" or "some_app" directory to load. For this the Bokeh server would need a new configuration option to explicitly state the locations that are OK to search in, and then it would need a new "catchall" endpoint in the Bokeh Tornado app to do the searching and app loading and installing.
"Automatic Detection" approach
------------------------------
This is basically similar to the last idea, a specified location for Bokeh server to look, but instead of loading apps from there on demand, the Bokeh server monitors it for new scripts and directories via polling or watchdog (similar to the first approach) This approach is a bit of a hybrid of the two ideas above.
Considerations
As mentioned above, these notions do not cover a "debug" mode where changing existing app source files cause the browser sessions to reload.
I think perhaps my initial inclination would be to lean toward the "On demand" approach. I think it avoids the complications of polling or watchdog. It would scale automatically when there are multiple bokeh servers behind a load balancer, though each "first hit" on a given server would incur the "on demand" startup cost. So it's maybe not ideal for the use case where the app loading itself is expensive. However, if app loading itself is expensive that has the possibility of blocking existing sessions in *any* case, which could be problematic. It's one reason starting all apps up front and using higher level orchestration would be recommended. It's possible in any of these cases that app loading could happen in a thread but that will start to get complicated.
I guess it would be good to get your thoughts re: do these proposals actually cover the use cases that people have in mind, and secondarily do any of them sounds more or less approachable or better for some reason.
Thanks,
Bryan
On Mar 6, 2018, at 23:26, Amogh Kulkarni <[email protected]> wrote:
I would be happy to contribute. Although I have a very limited experience in developing production software, I can certainly give it a shot and at least get it working so that it satisfies preliminary requirements.
Can you provide any pointers as to where I should start from?
Sent with Shift
On Tue, Mar 6, 2018 at 1:46 PM, Bryan Van de ven <[email protected]> wrote:
Alternatively, you could help stem the open source sustainability crisis by becoming a contributor. I'm certainly always happy to help any one get started. In particular, since this kind of feature would largely be on the python side only, it should be much more accessible to be contributors.
Thanks,
Bryan
On Mar 6, 2018, at 11:34, Amogh Kulkarni <[email protected]> wrote:
Well, looks like this is not supported in bokeh after all (seeing the response on this thread and the documentation).
I think there are other alternatives to bokeh if one has such an architecture in mind (adding the applications on the go). Dash by plotly for example. It looks much cleaner too.
On Sun, Mar 4, 2018 at 9:25 PM, <[email protected]> wrote:
I'm in a similar position. My ideal scenario would be to have a single bokeh server instance simply watching a directory into which I (or a CI process, whatever) can drop serialized json "apps", so that when users visit bokeh.mycompany.com/my-fancy-thing, it checks "live" if my-fancy-thing.json exists, and if so, establishes a session to decimate and stream the data from it to that user as they pan and zoom the plots in their browser.
Is there anything like this supported or on the horizon? I'm open to wrapping Bokeh Server in a small flask app that can do what I want by just spinning up new instances of the server on a per-app basis, but it would be helpful to have any pointers on this from others who have tried it.
M.
On Wednesday, February 28, 2018 at 8:50:43 PM UTC-5, Amogh Kulkarni wrote:
Hi,
I have used Bokeh previously in Jupyter notebooks but I am new to using Bokeh to build standalone applications. Can I run an instance of Bokeh server and keep on adding the applications on the go?
For example - I can run an instance of the bokeh server with the command
bokeh serve --show myapp.py
and it will serve the application written in myapp.py. Can I add another such file myanotherapp.py and make the same instance of the server serve it? I am avoiding having to spawn another instance of the bokeh server again.
Thanks,
Amogh
--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/7b718fe5-e815-4ab1-91ec-ac77656a3904%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.
--
Amogh Kulkarni
EMAIL: [email protected]
PHONE: +1 (615)810-7561
--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CABte%3DewcHnZAMnG0dmnMgM%3D9e%3D%2BWGjnRGzAcr6Q%3DxYsyJQ8g%3DA%40mail.gmail.com\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.
--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CF08E34A-B7A2-406B-8472-7C687466A0C1%40anaconda.com\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.
--
Amogh Kulkarni
EMAIL: [email protected]
PHONE: +1 (615)810-7561
--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/CABte%3DewV9iM6d5_xuTGeKQOhLrJmAdE_ZkdVmDMU_6CX%3DR0aig%40mail.gmail.com\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.