Make Event sync between instances in distributed setups

[rodja]

Motivation

Currently it's tricky to appreciate the Event demo in the documentation: when sending a "tweet" it only appears on visitors of the same instance. Due to the distributed deployment via fly.io, if a user opens two tabs, they have a high chance of landing on different instances.

Implementation

This PR is currently just an (AI-aided) sketch of an idea I had after some research. By using Zenoh to transparently sync events across instances. Zenoh is great for this because it does not need a broker or seperate server (like MQTT or Redis). Instances simply auto-discorver. To test it, I created a new example called distributed: A docker swarm starts three NiceGUI instances and a Traefik proxy in front:

Progress

• I chose a meaningful title that completes the sentence: "If applied, this PR will..."
• The implementation is complete.
  • error handling, edge cases, ... there is still much much to do before it might be ready
• Pytests have been added.
• Documentation has been added.
  • example
  • link to example
  • info in documentaiton

[rodja]

It might even be possible to create a ZenohPersistentDict and hence allow a distributed storage without a seperate Redis server. But we should leave that for an other PR.

[evnchn]

Could also make https://nicegui.io/documentation/refreshable#global_scope work, where we faking it with the use of Event

But in another PR.

[NiklasNeugebauer]

https://chatgpt.com/share/68f0d6ca-6f5c-800c-8d4c-2f7abbda6632

I wonder if the topic should be generated differently. In particular, I think events that are generated from a library like rosys would always result in the same topic right now.

I am not sure if it is worth considering this in the current state, but I wanted to leave a note here.
See the small chatgpt conversation about it above.

[falkoschindler]

Good point, @NiklasNeugebauer. Definitely worth checking.

---

I'm wondering if we really should add the code for distributed events into the Event class, or if something like a DistributedEvent inheriting from Event would be better. This would allow the user to explicitly create Events or DistributedEvents.

@rodja, you probably want a global switch ui.run(distributed=True) so that all events are distributed at once. But this feels a bit unintuitive and implicit to me. Is it clear to the user that this parameter affects all events (and nothing else)? And do we only have two use cases, either no event distribution or complete event distribution?

Maybe we need to think about specific real-world applications to answer such questions about the desired API. Since this PR is only a draft, there's no urge in answering them now. I just wanted to leave my thoughts here for reference.

[rodja]

[I wonder] if something like a DistributedEvent inheriting from Event would be better

Yes @falkoschindler. Feels great and keeps the responsibilities apart.

I wonder if the topic should be generated differently.

You are right @NiklasNeugebauer. It would be better to incorporate the app which is running into the auto-generated topic. Maybe the app title is unique enough in combination with the existing logic? Of course it should also be possible to optionally define your own topic string.

[NiklasNeugebauer]

I think some manually set instance id would be useful so that a user does not have to define every event topic but is still able to differentiate the instances (by version, specific application, whatever).