Hacker News Reader

Comment by bradgessler | Hacker News Reader

I agree with most of the points in this essay. I wrote http://firehose.io/ a few years ago for Poll Everywhere and we've successfully scaled WebSockets in a production environment. We don't use it for 2-way communications though; it's HTTP requests in and WebSocket pushes out with long-polling as a backup for non-WS clients. Check out the sourcecode if you want to see an implementation of all the "hard lesions won" in this essay.

I also gave a talk about it at RailsConf (http://www.bradgessler.com/talks/streaming-rest/) and learned that RabbitMQ as a backend isn't a great idea. Feel free to ask questions if you want me to dive into more specific points.

View on HN

Why was RabbitMQ not great as a backend?

I am curious because we use it for a not launched chat application (+websockets) currently and we are not sure if it will hold big amounts of users.

I found that it was difficult to deal with a web client connection dying, then reconnecting, and recieving messages it may have missed while disconnected. There's a flag you can set for this in Rabbit when creating a queue, but I couldn't really get it to work.

The way Firehose works the client gets a sequence ID per channel that's always counting up. If the connection drops when the client is on sequence 1, then 4 new message come in, and the client reconnects, it will get the rest of the messages up to sequence 5 and wait for new messages.

I have a question - if you're only using sockets for push, why not use SSE instead? Or did you encounter serious issues with that?

I've had good results with SSE in just the situation that GP describes: client actions come in as POSTs and the results of those are communicated to everyone via SSE. In most cases we don't even care about the 204 or whatever. If it's not on SSE then it didn't happen. b^)

SSE is fine except stupid Internet Explorer doesn't support it: http://caniuse.com/#feat=eventsource

A goal of Firehose is to have the fewest number of transports possible so the client doesn't have to spend much time negotiating the transport. I found WebSockets was more widely supported (http://caniuse.com/#feat=websockets) and HTTP long polling could take care of the rest.

Before I built Firehose I looked at socket.io, which had a ton of transports, but found that it was too slow, flakey, and unpredictable for our needs.

Reply on news.ycombinator.com