3 ms·

What happens over an unreliable network connection such as mobile?

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 ago
  So 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 ago
      you need a queue to do that properly, do your users have to manage that queue?
      - wenbo 4y ago
        Yes, developers will have to do this themselves for now.
    - deleted 4y ago
      [deleted]
wenbo 4y ago
I see that you worked on Firebase's Realtime database back in the day. How did your team handle such cases?
- tlarkworthy 4y ago
  queues either end. Clients are given a session ID, server (and client) replays missing messages on reconnect. It's the only way to achieve causal consistency, which is what you need for a sane programming model https://observablehq.com/@tomlarkworthy/redis-backend-1 https://observablehq.com/@tomlarkworthy/redis-backend-1
  - wenbo 4y ago
    Thanks, will take a look at your article!
    - tlarkworthy 4y ago
      I guess more important is that firebase transmits the current state of the database every reconnection

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 ago
So 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 ago
    you need a queue to do that properly, do your users have to manage that queue?
    - wenbo 4y ago
      Yes, developers will have to do this themselves for now.
  - deleted 4y ago
    [deleted]

wenbo 4y ago

I see that you worked on Firebase's Realtime database back in the day. How did your team handle such cases?

tlarkworthy 4y ago
queues either end. Clients are given a session ID, server (and client) replays missing messages on reconnect. It's the only way to achieve causal consistency, which is what you need for a sane programming model https://observablehq.com/@tomlarkworthy/redis-backend-1 https://observablehq.com/@tomlarkworthy/redis-backend-1
- wenbo 4y ago
  Thanks, will take a look at your article!
  - tlarkworthy 4y ago
    I guess more important is that firebase transmits the current state of the database every reconnection