Woe be unto you for using a WebSocket
I worked for a while on a well-known product that used (and perhaps still uses) WebSockets for its core feature. I very much agree with the bulk of the arguments made in this blog post.<p>In particular, I found this:<p>- Our well-known cloud hosting provider's networks would occasionally (a few times a year) disconnect all long-lived TCP sockets in an availability zone in unison. That is, an incident that had no SLA promise would cause a large swath of our customers to reconnect all at once.<p>- On a smaller scale, but more frequently: office networks of large customers would do the same thing.<p>- Some customers had network equipment that capped the length of time of that a TCP connection could remain open, interfering with the preferred operation<p>- And of course, unless you do not want to upgrade your server software, you must at some point restart your servers (and again, your cloud hosting provider likely has no SLA on the uptime of an individual machine)<p>- As is pointed out in the article, a TCP connection can cease to transmit data even though it has not closed. So attention must be paid to this.<p>If you use WebSockets, you must make reconnects be completely free in the common case and you must employ people who are willing to become deeply knowledgeable in how TCP works.<p>WebSockets can be a tremendously powerful tool to help in making a great product, but in general they are almost always will add more complexity and toil with lower reliability.<p>(edited typos)