[leesalminen]

I recently discovered Pusher and was able to build and ship an entirely new feature in under a week. They have good documentation, thought provoking example apps and simple pricing.

Couldn't be more impressed with them. Keep it up!

[graffitici]

Out of curiosity, if you were to implement the features of Pusher yourself, would it have added too much to your implementation? I guess you would need to set up your own Socket.IO server, and push data from that.

I've never implemented this, which I think is the reason I am underestimating the service that Pusher provides. It would be great if someone that did implement it would convince me that it would be a large hassle to do that internally.

[sondh]

I have come across Slanger[1] while researching for a good websocket server and it worked well for us. It's basically an open source version of Pusher backend. You may be interested in their code.

[1] https://github.com/stevegraham/slanger

[nulltype]

I haven't used Pusher or Socket.IO, so I don't know specifically what they offer. However, I have made a simple unidirectional websocket-type server and it was not a terrible hassle.

With a go server on a GCE n1-standard-2 you should be able to handle over 100k connections per server. I haven't done any benchmarks for throughput, but using redis as the messaging backend you can do pretty well.

You take 100k connections on each of the endpoint servers and make a single redis connection, using redis pubsub to subscribe to channels. Publishers can connect to the same redis and publish to those channels.

If you wanted bi-directional it could work a similar way I think, I'd guess the specific architecture depends on your requirements.

[morgante]

A single Socket.IO server is easy.

A scalable cluster of Socket.IO servers isn't.