In many various cases, a real time communication from the server to the client makes sense, and the microflow timer is not very elegant.
We offer the Pusher widget, but it relies on a third party, and even if there’s no real information traffic in this third party, it’s still a third party to trust.
As far as i understand the websocket capaility, it’s about establishing a connection of the backend with a realtime source (like datahub 2.0 events i suppose). Am I wrong ?
Because here we talk about the client.
Websockets are a fairly recent addition to the platform, making realtime communication possible.
https://docs.mendix.com/refguide/websockets-in-runtime
IMHO this would lift the functional power of the entire Mendix platform to a next level.
Some use cases:
- time-critical applications where a user is waiting for something to happen.
- applications where multiple persons manipulate data at the same time. Like sprintr, where during the rituals several consultants edit the same storyboard. Everybody will see the changes as soon as anyone saves changes to one of the stories.
- dashboards for routing applications. Would love to see the movements of each delivery-person real-time in one view.
The only alternative we have now is making every client poll the server for refreshed information. For instance with the microflow timer.
@Lennart: Pusher is Publish&Subscribe, so the app-server broadcasts messages to many subscribed app-clients. This websockets solution is full-duplex between any two parties, so one app-client and one app-server. Or is this also for shared websockets?