API is missing notification of reconnect thus unnecessarily limiting its utility

[igoodrich]

The Problem

Websockets are stateful conversations. When this library auto-reconnects, it doesn't tell anyone it's done so. The server just thinks it has a new connection unrelated to the previous on-going conversation. The client isn't given a chance to remind the server who it is and, in fact, has no idea that it's having an entirely different conversation as far as the server is concerned. It's a little like invasion of the body snatchers, tbh.

The Problem re: Phoenix

When you attempt to use this WebSocket module with phoenix, the phoenix server stores all the conversation's state, including what channels that have been joined, in the phoenix server's representation of the socket. When a reconnect happens, the new socket has none of that state. From the client's perspective, it's as if it's been dropped from all the channels but with no notification that that's happened. All messages from the server to the client come over channels, so the client will no longer get any messages and not even know that it needs to start waving its arms around wildly to get the server's attention.

I know there is a specific problem with phoenix, but I think the same problem would exist with any websocket approach as, again, it's a stateful conversation we're talking about.

The solution

The solution is fairly simple. This library should notify its clients upon reconnect. This will give the client a chance to tell the server who it is and that it needs a full dump of any missing state.

Not the solution

One might be able to cobble something together by sending a periodic "Here I am Identity Heartbeat" type message to the server that would let the server say "Wait! That's you! No way! You're way behind!" However, since that effectively is a poll it would need to be at some interval and during the interval the client might be woefully out of date. Depending on what you're doing, it might be okay. It's obviously not great though and kind of undermines the websocket thing for a lot of applications.

Not the solution either

I also don't think the solution is "just use the WebSocket.LowLevel stuff". That's not the solution because the fix is pretty easy and w/o the fix, sadly, I think the WebSocket module's use is fairly limited -- at least limited to applications that don't mind an occasional unrecoverable failure that manifests as...what was I saying. Also, there's a lot of complicated code in WebSocket.elm (thank you!) and it's really close to being quite useful for a wide set of purposes even with a low surface area API.