3 ms·
Wen Bo from the Supabase Realtime team here! Client will seek to continuously reconnect to the WebSocket when there's a connection issue and server must receiv
by wenbo 4y ago
Wen Bo from the Supabase Realtime team here!
Client will seek to continuously reconnect to the WebSocket when there's a connection issue and server must receive at least one heartbeat in a 60 second window; otherwise it will clean up the WebSocket connection.
We built Supabase Realtime on top of Phoenix Channel, and along with our clients, handles unreliable network connections gracefully, including on mobile.
- tlarkworthy 4y agoSo you will lose messages. "Phoenix uses an at-most-once strategy when sending messages to clients. If the client is offline and misses the message, Phoenix won't resend it. Phoenix doesn't persist messages on the server. If the server restarts, unsent messages will be gone. If our application needs stronger guarantees around message delivery, we'll need to write that code ourselves. Common approaches involve persisting messages on the server and having clients request missing messages. For an example, see Chris McCord's Phoenix training: client code and server code." https://hexdocs.pm/phoenix/channels.html https://hexdocs.pm/phoenix/channels.html It will be impossible to build a reliable mobile experience on top of such shaky foundations.
- wenbo 4y ago> So you will lose messages. This is true but you can store your messages inside your database and on reconnect you can fetch the messages you missed.
- tlarkworthy 4y agoyou need a queue to do that properly, do your users have to manage that queue?
- wenbo 4y agoYes, developers will have to do this themselves for now.
- deleted 4y ago[deleted]