WebSockets - Pusher/Pubnub versus Socket.io

[Matthew O'Riordan]

Seriously hoping that someone on this list has had some experience with WebSockets and the server solutions for it.  I'm in the process of evaluating whether it's better to run one's own Node server(s) with Socket.io, or use one of the well known realtime WebSocket services out there such as Pusher or PubNub that I am assuming will take away all the pain in regards to running the service.

I was really hoping (and will be most grateful) to get some advice from anyone who's possibly been there and done this already.  Any of your thoughts on the following would be hugely appreciated:

• If you've gone the paid route with Pusher or PubNub, why did you do that?  If home grown / Socket.io, why as well?
• Do you think the global presence of PubNub is that important when it comes to latency?
• Do you find Pusher/PubNub price prohibitive?  Based on my initial calculations, a few millions messages a month over SSL for $49 a month with Pusher seems fair, but do you think I'm off the mark perhaps?  I know Socket.IO is free, but it comes with a price tag once you start running the service yourself...
• Were there any particular features of PubNub or Pusher that you found extremely useful that Socket.IO does not have, such as private channels, or presence for example?
• Having done one or the other, any advice in retrospect?  Any difficulties, problems, or wishes?

Appreciate your feedback if you have any.

Thanks,

Matt

[Addison Higham]

At i.tv, we have played with pubnub and socket.io quite a bit.

I still really like pubnub, but with their shift in pricing in the last few months to limit concurrent connections, it seems like it would be much more expensive for apps with lots of users.

That said, if you have less than 2,500 simultaneous users, I think its awesome.

As far as self hosting, socket.io is really its own beast as far as ops are concerned. IMHO, it really should be separate from the rest of your apps, which means something else to manage. If you already have redis in your stack (which is the easiest way to communicate between socket.io instances) then it might be easier. We were a bit hesitant to add redis just for socket.io, so we never got to far with it.

Our current plan for anything we do with pub/sub is to start with PubNub, but wrap it in our own API so that we can easily dump it for our own solution. Thats the best part of PubNub, the api is so simple, it doesn't feel like you are tied to.

Let me know if you have more questions.

Addison

[Matthew O'Riordan]

Hey Addison

Thanks for the feedback, that's pretty useful stuff there.

I also saw the shift from the old PubNub model where connections were not limited to the new model where connections are, and I think it's because they're playing a bit of catch up with the Pusher business model whereby they limited the number of connections and forced you to sign up to a package.  It's a bit of a shame, but I suppose PubNub need to make money, and connections consume resources.

I am quite hesitant to host socket.io for a number of reasons, firstly it means I have more "stuff" to look after, and the more I look after, the more can break.  But I am also concerned that Socket.io on my own servers just won't give me an equivalent service in terms of latency around the world, constant monitoring of performance and I assume scaling of their service to meet demand, and feature wise I find Socket.io is pretty basic.  Did you consider Pusher btw?  Just wondering how you think the two fair.  Out of interest, why did you think of using PubNub and how did you come across it?

Good point re: simplicity of the PubNub API, it is stupidly simple, and that is good for portability reasons.

I assume you don't need features like presence that PubNub does not offer, but Pusher does?  

Also, are you using features like the history API?  

And one final question if you have the time, does the security model of PubNub not worry you?  I am a bit weary of pushing a private key out to the client in the browser as it's so easy to intercept.  Does that not concern you?

Matt

[Sean Hess]

One idea I had recently: Just use pubnub (or something similar). If it becomes too expensive, implement a socket.io based solution with exactly the same interface. Put your scale problems off till tomorrow!

[Matthew O'Riordan]

Fair enough, would be good if there was a more generic API for all of these services, shame there isn't…