Something that interested me when I first started hacking on NodeBB was how the platform uses realtime communication through socket.io (and websockets). This interest stems from work I did whilst working as a realtime engineer at Pusher several years ago. One of my research projects whilst there was to look into how websockets get used in production, and other use cases for websockets besides the standard "subscribe to a channel and receive events".
How NodeBB currently seems to use realtime communication:
RPC: Request data from the server, get a response back, present that data to the user (or send data to a server like you would POST to a HTTP server)
Channels: Used for user to user chat messages
Events: Used for online/offline states of users.
I may have missed something here, so, let me know if I have.
Most of the websocket usage appears to be in RPC style messages: Get this piece of data do something with it. At present, all realtime communication for NodeBB is built on top of Socket.io, which uses a protocol more tailored for event type packets, rather than for RPC style packets. For this, something like JSON RPC may be more appropriate.
For user-to-user chat messaging you could still multiplex that onto the same actual websocket / socket.io connection (although it's arguable if this is actually beneficial).
Why do any of this writing or work? Interest more than anything else, but it may make the code to NodeBB cleaner, and improve maintainability.
I think I have discovered another breaking change that you didn't mention, though it is probably super-niche.
This commit: https://github.com/NodeBB/NodeBB/commit/ec91ef1c644044bba44198b031913655e784b4bb
broke our custom SSO plugin. The result was that after successfully logging in our external identity provider and being redirected to our Forum's callback endpoint, I was ending up not logged in (the button in the header still said "Log in") and stuck on /register/complete roadblock. It looked like our Passport strategy verify callback, that parses output from the identity provider and fetches user data via OAuth2 was not invoked at all.
It turns out that the changes in this commit don't play well together with passport-oauth2 (https://github.com/jaredhanson/passport-oauth2) internal ability to protect against CSRF (which we were using). This strategy was already using state parameter to pass its own CSRF token. I don't have more time to investigate but I suspect things shipwrecked when NodeBB overwrote the state parameter with its own CSRF token.
Turning off passport-oauth2 internal CSRF protection (by removing state: true from its options) fixed the issue.
Ok, the Google ad will not show on the home page or category page, only on topic pages. Scripts from another ad provider does not work and the side will not load. The HTML widget, me thinks, should be able to render any HTML/JS script.