Bokeh apps intercommunication or data transfer

Hello,

I have a question about intercommunication between Bokeh apps. Is it possible to have apps have events that trigger updates between themselves? And more importantly through specific sessions? It was not obvious to me in the app_hooks.py from the documentation.

A more concrete example would be,

In app1 you have a button with a text widget, and when pressed is able to tell app2 what the data was in the text widget from app1, and display it or process it when the event occurs on app2.

Event           Capture Event
[app1] <---> [app2]
                    Process Response

I have seen some mention online of zeromq, but was curious about any built-in functionality. Would I need to deal with polling to see if an event occurs, or can I just trap that an event happened?

I am trying to keep bokeh apps separated from a django interface. It would be nice to decouple them, aside from a pull_session/server_session.

The motivation is to have smaller apps that use the bokeh layouts, but can be built into a more responsive layout.

Any guidance would be greatly appreciated.

Cheers,

Not really. I won’t say it is impossible, because this is Python, so you can more or less make anything “work” by banging on it hard enough. But this is not a use-case that has yet been considered or intended, and so there is definitely nothing built-in to Bokeh to support it.

I think you would need to embed Bokeh server programmatically, so that you could add add new handlers to the event loop for whatever external messaging system you wanted to integrate with (zmq or whatever), and then you’d have to find some way to communicate any results back to individual sessions. Speculating, a session could start a thread to watch some “external” data structure, and kick of “next tick” callbacks in response to changes. Or it might be possible to “push” changes to sessions from external handlers, tho I am not sure offhand.

The closest thing I know of that might like this is probably the Dask dashboard, which updates continuously based on telemetry updates coming in from a whole cluster of servers. I am not familiar with its specifics, though. You would have to go study it yourself to see if it does anything applicable.

Hi @Bryan,

Thanks for getting back to me.

This seems like a good extension for bokeh, almost like having an event_hooks.py that can be per document, or per session.

This is the ideal situation I am looking for. Do you think others would appreciate this functionality? I would have to learn about it but could be interested in trying to work on something. I assume you would need some token to ensure that random apps/sessions are not trying to hijack the current communication.

I will take a gander at this.

Thanks again!

I think it could be useful, in the abstract, but there has also not been many folks asking for it, at least that I have seen. There are also certainly questions to answer. Offhand, pushing to a session seems fragile, since if the user re-loads the page, now they are in a new session. (Unless you embed a fixed session id/token in the URL, but is uncommon usage). I think a more detailed proposal or even a basic proof-of-concept would go a long way towards focusing a discussion.

Yes I can, see that being an issue. I think within a session you just want the apps interconnected to display the correct information to the user/viewer. So if you reload a page (for whatever reason) the apps on display would be still interconnected, even if on a new session. This would be basic, but still useful. Possibly something that should only be implemented with signed sessions?

That is fair and I agree. I am more thinking of a series of apps hosted on one bokeh serve instance, only they have the ability to interconnect. I mean you could have separate bokeh servers do this which opens up lots of opportunities with different hosts (and a plethora of security concerns).

I could try to think of something, but have never put forward a design proposal.

@ddkn It doesn’t have to be anything too formal. Mostly a real working PoC would be the best. From that, we can ask “what minimal changes in the library could make this real, existing thing simpler/better to accomplish” instead of lots of bike-shedding over hypothetical requirements.

@Bryan Okay, sounds good! I will see what I can come up with code wise, or if/how this may be feasible. If I could ask one favour, any places in the code base that would be a good starting point you can think of? I may look at how the hooks interface with the code (at least naively starting there). I am assuming having a good understanding of Tornado will be of use for this?

If it becomes too daunting, I will comment here on any pitfalls or problems, etc…

All the server functions were converted to native async years ago, we mostly just use Tornado for its event loop, since that’s what we started with originally. We do use Tornado’s auth decorator to hook in our own auth hooks API, but that’s about it.

If it becomes too daunting, I will comment here on any pitfalls or problems, etc…

Happy to try to answer any questions

I really dig bokeh, so I want to make it do more cool things that others could find handy. Will keep you posted. I have some reading to do now, haha.

After spending some time looking at this, I think I am trying to use a hammer to drive in a screw. I may look at using Angular + BokehJS which communicates with django, as that seems a more natural fit. Which obviously complicates the solution to the problem, but this seems to be a better course of action.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.