🚀 Feature: Websocket Connect and Disconnect Events

[Towerful]

🔖 Feature description

Have the Client.Realtime emit events when the websocket connects and disconnects

🎤 Pitch

Currently there is no way to detect this.
If the websocket disconnects and you are relying on the realtime connection to track data between the client and the database, you will miss CRUD events, and your client data may not reflect the database data.
With events indicating WSS connect and disconnect, this would allow feedback to the user that it is no longer realtime, and to do a full data refetch/refresh when the websocket connects.

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[Steven Nguyen]

@Towerful, thanks for creating this issue! 🙏 Is this a duplicate of appwrite/appwrite#2418? If so, can this be closed?

[Towerful]

I don't think it is, perhaps I didn't explain myself well.
However I didn't check appwrite/appwrite for duplicates.

I feel like that appwrite/appwrite#2418 is a server side feature. When a client disconnecting would trigger a function on the server, in order to track some sort of presence.

I would be looking for client side events regarding the websocket connection status.
I don't believe there is any "event replay" from the server to tell the client the events it missed while the client was disconnected.
So if I have local state on the client, and I am relying on the websocket to modify that local state according to the create/update/delete events in order to reflect the actual data on the server, the clients local state will no longer be in sync with the server data due to the events it missed when the websocket was disconnected.
The user may not realise that they have stale data, as they will still get further updates. But the existing client state will likely still be stale, as they have missed the chain of events between the disconnect and the reconnect.

Having a 'socket disconnected' event raised would allow me to tell the user the client has disconnected.
Having a 'socket reconnecting' event would allow me to tell the user the client is trying to reconnect, and what attempt number it is.
Having a 'socket connected' event would allow me to re-run all my database queries to fetch fresh data, so the client can then track the server data correctly.

I hope that makes sense.

The events could be implemented as an event, for example:

{
    events: ['realtime.disconnected'];
    channels: string[];
    timestamp: number;
    payload: { };
}

{
    events: ['realtime.reconnecting'];
    channels: string[];
    timestamp: number;
    payload: { 
        attempt: number,
        timeout: number
    };
}

{
    events: ['realtime.connected'];
    channels: string[];
    timestamp: number;
    payload: { };
}

which could be raised for all subscribed callbacks.

I don't think this would be a breaking change, as implementations normally rely on events.includes('databases.*.collections.*.documents.update') to test if an event is relevant.
As these websocket events would be namespaced under realtime, this shouldn't break existing functionality.