You might not need a WebSocket

Indeed. These days, you have to expect users will wander out of their wi-fi range or have crappy mobile connections. Whenever I ride the train with my 4G tether, my TCP sockets die every few miles.

I lose ssh and my websockets, but long-polling apps keep working. Kind of ridiculous, but that's the world we live in.

Making your websockets resilient means pinging and aggressive reconnecting.

Also it just completely falls down in the case of many proxy servers and often the end user has no control over that.

So if connection resets are the problem, as opposed to router/proxy software problems... In cases where long polling seems to work as you say, why wouldn't an automatic WebSocket reconnect work just as well?

Modern setups don't even involve spawning a new thread per request anymore as even that doesn't scale well enough.

>> most servers don't make a new process for every request anymore

That's correct. Most designs use either a prefork model (e.g. Apache) or an asynchronous event-driven model (e.g. Nginx). With prefork, a number of worker threads or processes are created on start up, and each services one request at a time. In the asynchronous model, a smaller number of (typically single-threaded) processes are created on start up, and each services one event at a time. An event could be an incoming request, a database query returning, etc. In either model, thread/process creation typically happens entirely on start up.

Interesting! I'm surprised that browsers wouldn't batch up many outbound messages into single TCP frames. The server behaves more the way I would expect.

That reminds me of a related point: The number of TCP frames can be considered more important than the number of bytes-per-frame when it comes to network performance. Most message exchanges, whether over WebSocket or HTTP, will occupy a comparable number of TCP frames, even if HTTP uses more bytes for the headers.

If notifications only go one way, server side events should also be considered.

...but I don't remember the advantages anymore :)

WebSockets are super easy to use (we still love it offer support for it), but if your users are on older devices or browsers you're going to run into problems.

You also have to take into consideration different network issues, for instance last year Verizon 3G blocked WebSockets without any documentation. Or fragile wireless networks where the socket will break.

SSE is also a proper solution. If you have a REST setup, you can use the same HTTP resources for both pulling and pushing.

If I understand your first problem correctly, you could have setup an RPC system so you only write your apis once. Use the same 'endpoint' of your api as the data call in your socket connection, and you only end up writing your api once.

Fanout's great for powering a public-facing realtime API. For example, you can see what Superfeedr did with it here: http://blog.superfeedr.com/stream-superfeedr/

If you're not making an API, and you're just pushing data to your own client applications that you control, then Pusher and Fanout are more or less the same. Although you might like Fanout's simpler pricing model and our more open philosophy.

Are you using WebSockets in a big production environment or just for hacks/projects?

Conceptually, polling just seems dirty.

if (some event occurred){ do something over and over every so often that requires multitudes of processes including authentication, DNS etc. across many machines, that might not even ever return any value to the user. }

is not as nice as,

on('the arrival of a message', doSomething)

edit: pardon the sloppy pseudo syntax...

Mostly technical, I need the performance, and my problem maps pretty well to raw sockets. The application I'm currently writing can push upwards of 60msgs/sec to the websocket client.

Using long-polling, etc. this just doesn't seem feasible. I'm sure my HTTP stack _could_ push small messages in <17msec fairly reliably... but that's not what it's built to do.

Tossing the request all the way down my HTTP stack just seems wasteful. There might be middleware hitting persistent caches, there might be a reverse proxy out in front, etc. -- This all takes non-negligible resources away from other requests, and this all takes time.

---

I should note that I do use SSE or long polling for things like event notifications. So in the end I fully agree with the article. WebSockets are not a tool that should be applied haphazardly. In my stack WebSocket upgrade requests hit an entirely different server, so I take great care in electing where to use them.

I used Socket.io for my site, so I don't care what the implementation. I just needed a way to push realtime events to the user.

Side note: Thinking about switching to SockJS since I use 1% of Socket.io features, but it's working well as is

I don't use WebSockets mostly because of general lack of support and stability in the frameworks I use and clients I want to support. I typically use an in memory buffer server side of events generated to send down, the client polls (as rapidly as desired, sometimes on the minutes time frame, sometimes on the seconds) passing up the last package ID it received (or nothing if it's just starting up). The server from memory sends back all messages it has as the delta. This combined with keep-alive has worked rather well. I would not recommend this for mobile users or users who would be on metered connections, but the behavior of the client is easy to implement using ajax and throttling on the javascript side. By it's nature it automatically recovers from network drops or reroutes with no additional logic.

For me it was just "the thing everyone was talking about". Was amazed when I discovered EventSource and puzzled why it wasn't more widely known. Axed the socket.io complexity immediately. Thanks for putting the word out about this!

I suspect we originally started using WebSockets because of the bandwagon, but it still feels like what we want. We use them to subscribe to various message feeds; client->server messages are used to add/remove subscriptions and server->client push messages that are on the subscribed feeds.

We have a small abstraction over the browser WebSocket object that gives auto-reconnect (and catches disconnects through polling frames) and an interface that looks more like a Node.js EventEmitter. We fall back to (normal) polling if the socket takes more than a few seconds to connect.

I like this. The other day we were thinking about how the suggested practice these days is to start with long-polling first, then attempt to upgrade to WebSockets (as opposed to the other way around). But, in some cases it's not the browser but the network that prevents WebSockets from working. This means if you wander to another network that doesn't support WebSockets, you actually still want a way to downgrade back to long-polling.

Maybe such best practices could also include some kind of poll/ping interval that adjusts based on the apparent stability of the link. Stable or wired connections could have very large intervals.

Server-Sent Events have quicker handshake, send events down just as fast as WebSockets, and automatically reconnect (so works like WebSocket on stable connection, long polling on unstable).