🚀 Feature: Replace Websocket by Server Sent Events

[fliitor]

🔖 Feature description

Replace Websocket by SSE , wich is browser native

🎤 Pitch

If I'm not mistaken, realtime is currently used in one direction only (data updates are done via SDK, not websocket) so losing bidirectionnal feature isn't a big deal (otherwise I wouldn't propose the replacement)

SSE allow automatic reconnection, stream resume, works with HTTP protocol and bypass proxy protection (thanks to use of http)
This would also make it possible to use realtime in the backend ?
Works with HTTP protocol also mean compression, easier handshare / session management,

I don't know enough about the realtime source code to realize whether the two can coexist, and have a configuration via environment variables (or in the console) to have one or the other (or both?). But of course the change should not be so complicated, as the trigger would remain via the resque tail.

It should also mean less maintenance, as it's based on a standard and doesn't need an external library to work.

More read

• Appwrite issue (for realtime)
• Why use Server-Sent Events over WebSockets?
• OR wait some years and change to WebTransport ^^

👀 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

[fanatic75]

It's a wise decision to utilize Server-Sent Events for functionalities that don't require continuous communication, but it's also crucial to acknowledge the significance of web sockets. Rather than replacing web sockets, server-sent events can be incorporated as an additional communication method from the server to the client.

Do you have any thoughts on this, @eldadfux?

[tripolskypetr]

You can use BFF pattern to overcame WebSocket restriction by restreaming AppWrite Realtime events into sockjs channel https://github.com/react-declarative/nestjs-appwrite-bff