WebAgg for multiple clients

[bmu]

I just integrated the webagg backend in a tornado application to visualize some data.

However the problem is, that a user on one client can manipulate the figures on another client. Maybe this is a problem of my application, but I think it would be awesome if you could really integrate the webagg backend in a multi client application.

I would like to implement something to separate this, e.g. creating a new figure for every request and using a separate websocket for every client, however I a not sure how to do this.

Do you have any ideas?

[mdboom]

Yes -- the multiple clients/one figure mode is how the built-in WebAgg server and the embedding_webagg.py example work, but there's nothing saying it has to work that way. Have you looked at the examples/user_interfaces/embedding_webagg.py example? It should be possible to create a new figure when the page is loaded, and pass around the figure id in the URL to create get sockets for it, etc. (rather than using the single "manager" that's stored in the example application now).

[bmu]

I looked at the example, however I think its the same in the build-in WebAgg serrver: if you open two tabs in a browser you can manipulate the figure in the other tab.
I was trying to open different websockets for every figure, but I'm not sure if this is the right way, as I read somewhere that browsers will limit the number of open websockets.

[mdboom]

It is the same as the built-in webserver -- it will have to be modified to create a new figure and route a new web socket to it with each page request. You will need a separate websocket per figure, but the number should remain quite low per browser...

[bmu]

I tried to implement this, but now I have the problem, that the figure is not shown.
The code is on https://github.com/bmu/webagg_examples and I will further work on it.

If I look at the tornado demos it seems that the usual programming style is to define RequestHandlers outside of the application, which is what I did. Maybe this is a reason for my problems, but I'm not sure (I used the application to store the figures and managers). Are there any reason, that you defined everything under the application?

In general I think it would be useful, if the embedding_webagg example could look more like the tornado demos.
Or even more, maybe this could be implemented as a tornado UIModule and would be easy to use in any application (however I am not sure, if this is possible).

[tacaswell]

@mdboom Not sure what to do about this one.

[tacaswell]

Closing due to inactivity. @bmu If you are still working on this please ping me to have it re-opened.

[raphaelquast]

Recently I wanted to create a multi-client webagg server and even though this issue is ~10 years old, it was the only helpful source of information I could find...

The good thing is that it was enough to get things started and now I have a working example for a multi-client setup!
(e.g. a server that spawns a new figure + websocket on each get request)

In case anyone is still interested, let me know!

[tacaswell]

@raphaelquast could you share a reference?

I also have a very rough prototype of serving mpl figures via fastAPI https://github.com/tacaswell/matplotlib-fastapi

[raphaelquast]

@tacaswell
Thanks for sharing the fastAPI code! I'm quite new to all the web related things so template-repos are really helpful!

I quickly created a repo that contains a minimal example for my tornado multi-client setup:

• https://github.com/raphaelquast/mpl_webagg_multiclient
  Let me know if you have any comments!

You might also be interested in having a look at my latest PR (#27160) which fixes webagg performance issues when using callbacks that trigger draw (or blit)-events in webagg.