plugins.registerHook removed, use plugins.hooks.register
plugins.unregisterHook removed, use plugins.hooks.unregister
plugins.fireHook removed, use plugins.hooks.fire
plugins.hasListeners removed, used plugins.hooks.hasListeners
Socket.io v1.0 released!
Very very excited about this! Hopefully the migration goes smoothly
What does this mean for the masses? Good things? Temporarily rocky things?
As you know, we use socket.io to power our real-time aspect. They've been on 0.9.16 for the better part of a year (perhaps more), while the team (a small one, like ours) has been working to refactor the underlying engine to a more stable, secure, and powerful one.
Off the bat, it generally means one thing -- that those users who can't access NodeBB for whatever reason due to their ISP (websockets blocked, etc) will no longer experience a "delay" before NodeBB starts working*. Some users (less than 1%) can't even use a NodeBB at all, because the mechanism that drops a websocket connection back down to XHR-based doesn't kick in.
Both of those problematic cases will be resolved when NodeBB is upgraded to use socket.IO v1.0.
* The way this works is: NodeBB loads, and attempts to establish a websocket connection. If after a delay, a connection isn't made, it falls back to xhr polling. Socket.io 1.0 will do this in reverse, xhr first (works in 100% of cases), and upgrade to websockets.
dibu last edited by
As you know, we use socket.io to power our real-time aspect.
I have a couple of questions:
- Is upgrade to socket.io 1.0 planned?
- There are other alternatives to socket.io like sockjs, primus, faye is socket.io better?
- Is it possible to scale socket.io (multiple thread, servers) used in NodeBB? (Can you share your experience?) In some posts you mentioned that this forum was running on the server with 512Mb of RAM. What was the peak or average amount of simultaneous socket.io connection using this amount of RAM?
We're looking to upgrade to socket.io 1.0 as soon as possible. We're blocked by an upstream module that allows us to listen to hook into all incoming events, instead of setting up listeners for each event. (for more information: lmjabreu/socket.io-wildcard#5)
Other alternatives may be better, we have not tested them as socket.io has performed admirably in all of our use cases.
We didn't do any benchmarks, unfortunately
We are now waiting for an upstream PR to be merged:
Hello @julian - do you think this update could solve this issue?
looking foward !
Still waiting on upstream pull request to be merged
Sounds like great news, looking forward to seeing NodeBB bloom using it