Well, there's a lof of information about websockets. The technology itself is amazing, there's no doubt in this fact. And before i will start using them in my app i just want the community to answer these questions:
"...in order to maintain presence, the app can send keep-alive messages on the WebSocket to prevent it from being closed due to an idle timeout..."
"...ideally a future version of WebSocket will support timeout discovery, so it can either tell the application the period for keep-alive messages..."
This feels like deja vu. Earlier we had to poll the server once a %period_time% to get the needed updated information. With websockets we have to poll the websocket server once a %period_time% with keep-alive messages to make sure the internet connection is still alive / the websocket server is still working. What's the profit?
And another thing regarding these keep-alive messages. Websocket protocol has an advantage of using less traffic than HTTP(S). If we send keep-alive messages, it seems like the traffic advantage dissapears. Or maybe not?
How should i handle the loss of internet in my app if i use websockets? I mean the real situation when the internet connection is suddenly lost (i mean no "navigator.offline" event has happened). Should i use some kind of setTimeout-function to look for keep-alive messages or is there a better way to handle this situation?
REST gives us a clear understanding of how an app should work and how the requests should look like. What's the best way of doing this in websocket-powered apps? Should i just have (say) JSON-encoded messages with request.action field it it? And how should the app perform PUT-requests? There are URL-resources in REST model to handle this, so should i use combination of these approaches or maybe is there smth simplier?