What do you have to run?

Use a Socket.IO client in the app and a matching server. The server puts connected clients into rooms and sends events to the relevant room. For a shared board, keep the board records in your database and use a room event to tell the screen about a change.

A plain WebSocket client does not speak the Socket.IO protocol. Check that the hosting setup supports your server’s connection method before relying on it.

Does signing in let someone join every room?

Check who the account is when it connects and verify board membership before the server adds it to a room. Check permissions again when the app receives a request to change a saved task.

Connection middleware runs when a connection is established, and an optional recovery setting can skip it for a recovered session. Decide how your app will handle a person losing access while a connection is open or recovering.

What does reconnecting actually recover?

By default, Socket.IO preserves order for events that arrive, but the server does not replay events a client missed while disconnected. Give the screen a way to read the current saved board when it opens or reconnects.

Connection state recovery is optional. It can restore a short-lived session and missed events when enabled and supported by the server setup. Recovery can still fail. With multiple servers, check your message adapter’s support. The regular Redis adapter and the Redis Streams adapter have different recovery support.

How can you see the default gap on your own server?

Use a local Socket.IO server and two browser profiles with made-up board members. Confirm that the app’s data, sign-in and event targets are disposable and that optional recovery is off. If you cannot verify that, walk through the sequence on paper.

Check an event while connected
Open the sample board in both profiles. Have one member save In progress. Confirm the other receives the event and the task is saved.
Take only the receiving browser offline
Disconnect the receiving profile and confirm its Socket.IO connection shows as closed. Leave the writing profile connected and save Done once. Verify from the writing profile that the save succeeded before reconnecting the receiver.
Check live events and saved data separately
Reconnect the receiving profile. Check its received-event log for the Done update missed while offline. With Socket.IO recovery off and no replay built into your app, that event should be absent. Then check the result of the reconnect read or reload the board to fetch the saved task. The saved task should show Done. If you cannot see the event and the read separately, inspect the reconnect handler and saved-state request instead of using the screen alone as proof.
Check which part failed
If the saved-state read still shows In progress, check that the write was stored and that the reconnect handler reads the same test board. If you enable recovery later, repeat the test and also try an interruption beyond the configured recovery window.

What changes when one server is no longer enough?

Socket.IO is open source under the MIT license. Budget for the server, its memory and network use, and the staff time to monitor it. Connected clients and the number of events sent and received affect server load.

With more than one server, use a compatible adapter to forward events between servers. If you keep HTTP long-polling, configure the load balancer so requests for the same connection reach the same server. Recheck access, delivery and recovery with that actual setup.