5 ms·

It'd be nice if the socket.io project spent less time adding features and more time just documenting what they have. Does anybody have a small, fast, no-bullsh

It'd be nice if the socket.io project spent less time adding features and more time just documenting what they have. Does anybody have a small, fast, no-bullshit, modern websockets library they'd nominate for use with node?

yid 11y ago
Absolutely! I've had terrible experiences with vanilla socket.io regarding reconnections, performance, and reliability. This is even after the 1.0 release. Lately, I've been using primus [1], which is an API unification layer for socket.io, sockjs, faye, and native websockets. Swapping one engine for another is trivial, and they've taken pains to abstract a core subset of functionality. [1] https://github.com/primus/primus https://github.com/primus/primus
- STRML 11y ago
  +1 for Primus. We moved to it on BitMEX from a custom SockJS + Mux-demux setup and the transition was painless. We now get the ability to change transports based on client (so our API clients get the very fast standards-compliant node `ws` library, while browser clients get engine.io). We also gained reliable heartbeating which was a big win. I've found the devteam to be really responsive and their choices of abstractions appear to work well.
- amluto 11y ago
  Agreed. Mostly quoting myself from earlier this year: I don't normally like bashing open-source projects, but socket.io should not be used. It may be noob-friendly, but that's just because it does things so automatically that you can't really use it correctly. When I was a websockets noob, I used socket.io briefly, and it was a complete waste of time. See, for example, https://github.com/Automattic/socket.io-client/issues/572 https://github.com/Automattic/socket.io-client/issues/572 (closed without comment). SockJS is much better, as is raw websockets. Presumably Primus, too, although I'm a bit surprised that one can come up with a sensible interface that can be layered over both Socket.io and anything else.
AhtiK 11y ago
I moved to SockJS [1]. Socket.io itself was great but I had serious trouble to get socket.io server (gevent-socketio) working with Python and Flask. SockJS has a decent JS client-lib and a good set of server counterparts. Node, python, erlang and java (using Vert.x). Vert.x [1] combined with SockJS is especially powerful -- vert.x supports so called 'verticles' in multiple languages (JavaScript, Ruby, Java etc) that are running as tiny servers who can communicate over eventbus. Then the SockJS lib can be used to handle communication between the browser and Vert.x eventbus. Probably not intended but I'm also using SockJS to communicate events between a Flask app in python and Vert.x java verticle. [1] https://github.com/sockjs/sockjs-node https://github.com/sockjs/sockjs-node [2] http://vertx.io/ http://vertx.io/
efbenson 11y ago
We use ws(https://github.com/websockets/ws https://github.com/websockets/ws) in prod. Clean, fast, and simple. Plus it supports browsify using native implementation but wraps it to fit the server side api.
pacalleri 11y ago
Same bad experience here with socket.io. I switched to Faye (http://faye.jcoglan.com/ http://faye.jcoglan.com/) an implementation of Bayeux protocol programmed by James Coglan. I'm using the node version of the library in my games for 4 years with excellents results.
- antoniuschan99 11y ago
  How are you scaling it? I'm using the Ruby version along with eventmachine but max concurrent connections was 1024.
  - bighead 11y ago
    sounds like you're hitting the ulimit for your server process, rather than a issue with Faye itself.
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
leggetter 11y ago
SockJS is definitely a reasonable choice as a base. At Pusher we use a fork of SockJS for HTTP fallback but we actually use em-websocket [1] (ruby) for our WebSocket API. Given the opportunity we'd probably move away from SockJS to something much simpler because we only want the HTTP fallback part and it only handles < 8% of our connections. If you _only_ want WebSocket connections with no HTTP fallback then Faye WebSocket [2] may be an option. But any production application is going to require fallback for older browsers and pesky proxies/firewalls. Faye [3] is solid (obviously used Faye WebSocket), has implementations in Node and Ruby, but is a PubSub solution. I'd kinda argue that any real-time app needs at least PubSub functionality anyway. The ws Node module [4] is apparently "The fastest RFC-6455 WebSocket implementation for Node.js" and receives contributions from 3rd-Eden who is also behind Primus [5]. But it's also WebSocket with no fallback. I haven't used Primus, but I really like the idea of offering a layer above the underlying connection engine. I've seen contributions to Socket.IO dip in the past (prior to CloudUp being acquired by Automattic), but Socket.IO is used by so many apps that somebody is always likely to maintain it for the foreseeable future. I'm generally in favour of adding abstractions around layers like this (connectivity, DBs, Message Queues, Hosted Services etc.). However, in this case you're then adding a dependency on Primus. Isn't software fun! [1] https://github.com/igrigorik/em-websocket https://github.com/igrigorik/em-websocket [2] https://github.com/faye/faye-websocket-node https://github.com/faye/faye-websocket-node [3] http://faye.jcoglan.com/ http://faye.jcoglan.com/ [4] https://github.com/websockets/ws https://github.com/websockets/ws [5] https://github.com/primus/primus https://github.com/primus/primus
- jkarneges 11y ago
  What's great about SockJS is it's meant as a WebSocket polyfill and nothing more. It also has some semblance of a protocol definition. This makes it an ideal foundation to build upon if what you really want is WebSockets, but you need a bandage for old browsers. Meteor notably uses SockJS as part of their DDP spec. Also Pushpin includes a SockJS to native WebSocket translator.
  - leggetter 11y ago
    It does seem to be the most commonly used WebSocket polyfill around. We also use web-socket-js [1] for fallback. But Version 3.0 of pusher-js [2] will remove that. One negative with SockJS has been the complexity of the fallback approach on the client (the browser). Especially when it's only for 8% of connections. A single simple cross-browser HTTP-based transport would remove the code complexity and reduce the file size. [1] https://github.com/gimite/web-socket-js https://github.com/gimite/web-socket-js [2] https://github.com/pusher/pusher-js/tree/r3.0.0 https://github.com/pusher/pusher-js/tree/r3.0.0
thedufer 11y ago
I use [ws](https://github.com/websockets/ws https://github.com/websockets/ws). I've never had any trouble with it, and it benchmarks well. Of course, there's no fallback there; just websockets. I haven't seen a websocket+fallback lib that seems like it will work well. Requiring sticky sessions and disallowing using node's cluster module is the norm, and neither of those are appealing. We've rolled our own polling fallback, which is also used to cleanly handle missed messages during a websocket reconnect.

yid 11y ago

Absolutely! I've had terrible experiences with vanilla socket.io regarding reconnections, performance, and reliability. This is even after the 1.0 release. Lately, I've been using primus [1], which is an API unification layer for socket.io, sockjs, faye, and native websockets. Swapping one engine for another is trivial, and they've taken pains to abstract a core subset of functionality. [1] https://github.com/primus/primus https://github.com/primus/primus

STRML 11y ago
+1 for Primus. We moved to it on BitMEX from a custom SockJS + Mux-demux setup and the transition was painless. We now get the ability to change transports based on client (so our API clients get the very fast standards-compliant node `ws` library, while browser clients get engine.io). We also gained reliable heartbeating which was a big win. I've found the devteam to be really responsive and their choices of abstractions appear to work well.
amluto 11y ago
Agreed. Mostly quoting myself from earlier this year: I don't normally like bashing open-source projects, but socket.io should not be used. It may be noob-friendly, but that's just because it does things so automatically that you can't really use it correctly. When I was a websockets noob, I used socket.io briefly, and it was a complete waste of time. See, for example, https://github.com/Automattic/socket.io-client/issues/572 https://github.com/Automattic/socket.io-client/issues/572 (closed without comment). SockJS is much better, as is raw websockets. Presumably Primus, too, although I'm a bit surprised that one can come up with a sensible interface that can be layered over both Socket.io and anything else.

AhtiK 11y ago

I moved to SockJS [1]. Socket.io itself was great but I had serious trouble to get socket.io server (gevent-socketio) working with Python and Flask. SockJS has a decent JS client-lib and a good set of server counterparts. Node, python, erlang and java (using Vert.x). Vert.x [1] combined with SockJS is especially powerful -- vert.x supports so called 'verticles' in multiple languages (JavaScript, Ruby, Java etc) that are running as tiny servers who can communicate over eventbus. Then the SockJS lib can be used to handle communication between the browser and Vert.x eventbus. Probably not intended but I'm also using SockJS to communicate events between a Flask app in python and Vert.x java verticle. [1] https://github.com/sockjs/sockjs-node https://github.com/sockjs/sockjs-node [2] http://vertx.io/ http://vertx.io/

efbenson 11y ago

We use ws(https://github.com/websockets/ws https://github.com/websockets/ws) in prod. Clean, fast, and simple. Plus it supports browsify using native implementation but wraps it to fit the server side api.

pacalleri 11y ago

Same bad experience here with socket.io. I switched to Faye (http://faye.jcoglan.com/ http://faye.jcoglan.com/) an implementation of Bayeux protocol programmed by James Coglan. I'm using the node version of the library in my games for 4 years with excellents results.

antoniuschan99 11y ago
How are you scaling it? I'm using the Ruby version along with eventmachine but max concurrent connections was 1024.
- bighead 11y ago
  sounds like you're hitting the ulimit for your server process, rather than a issue with Faye itself.

deleted 11y ago

[deleted]

deleted 11y ago

[deleted]

leggetter 11y ago

SockJS is definitely a reasonable choice as a base. At Pusher we use a fork of SockJS for HTTP fallback but we actually use em-websocket [1] (ruby) for our WebSocket API. Given the opportunity we'd probably move away from SockJS to something much simpler because we only want the HTTP fallback part and it only handles < 8% of our connections. If you _only_ want WebSocket connections with no HTTP fallback then Faye WebSocket [2] may be an option. But any production application is going to require fallback for older browsers and pesky proxies/firewalls. Faye [3] is solid (obviously used Faye WebSocket), has implementations in Node and Ruby, but is a PubSub solution. I'd kinda argue that any real-time app needs at least PubSub functionality anyway. The ws Node module [4] is apparently "The fastest RFC-6455 WebSocket implementation for Node.js" and receives contributions from 3rd-Eden who is also behind Primus [5]. But it's also WebSocket with no fallback. I haven't used Primus, but I really like the idea of offering a layer above the underlying connection engine. I've seen contributions to Socket.IO dip in the past (prior to CloudUp being acquired by Automattic), but Socket.IO is used by so many apps that somebody is always likely to maintain it for the foreseeable future. I'm generally in favour of adding abstractions around layers like this (connectivity, DBs, Message Queues, Hosted Services etc.). However, in this case you're then adding a dependency on Primus. Isn't software fun! [1] https://github.com/igrigorik/em-websocket https://github.com/igrigorik/em-websocket [2] https://github.com/faye/faye-websocket-node https://github.com/faye/faye-websocket-node [3] http://faye.jcoglan.com/ http://faye.jcoglan.com/ [4] https://github.com/websockets/ws https://github.com/websockets/ws [5] https://github.com/primus/primus https://github.com/primus/primus

jkarneges 11y ago
What's great about SockJS is it's meant as a WebSocket polyfill and nothing more. It also has some semblance of a protocol definition. This makes it an ideal foundation to build upon if what you really want is WebSockets, but you need a bandage for old browsers. Meteor notably uses SockJS as part of their DDP spec. Also Pushpin includes a SockJS to native WebSocket translator.
- leggetter 11y ago
  It does seem to be the most commonly used WebSocket polyfill around. We also use web-socket-js [1] for fallback. But Version 3.0 of pusher-js [2] will remove that. One negative with SockJS has been the complexity of the fallback approach on the client (the browser). Especially when it's only for 8% of connections. A single simple cross-browser HTTP-based transport would remove the code complexity and reduce the file size. [1] https://github.com/gimite/web-socket-js https://github.com/gimite/web-socket-js [2] https://github.com/pusher/pusher-js/tree/r3.0.0 https://github.com/pusher/pusher-js/tree/r3.0.0

thedufer 11y ago

I use [ws](https://github.com/websockets/ws https://github.com/websockets/ws). I've never had any trouble with it, and it benchmarks well. Of course, there's no fallback there; just websockets. I haven't seen a websocket+fallback lib that seems like it will work well. Requiring sticky sessions and disallowing using node's cluster module is the norm, and neither of those are appealing. We've rolled our own polling fallback, which is also used to cleanly handle missed messages during a websocket reconnect.