4 ms·
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 u
by graffitici 11y ago
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.
- morgante 11y agoA single Socket.IO server is easy. A scalable cluster of Socket.IO servers isn't.
- nulltype 11y agoI 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.
- sondh 11y agoI 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 https://github.com/stevegraham/slanger
- deleted 11y ago[deleted]