Nodebb partitioning code

NodeBB Development
  • I'll work in my research with 'late distribution'. This is a term adopted by me rs. It means that I need to split the code to work in multiple clouds. For example, the 'module' topics would be deployed in Amazon EC2 to use the load balance and the rest of nodebb code in GAE, implementing some communication between the code on the EC2 and GAE. Some ideas?

Suggested Topics

  • 11 Votes
    7 Posts

    Updated successfully!

    looks very good, thanks guys 😄

  • 0 Votes
    2 Posts

    I git clone v1.x.x branch.
    today I git reset --hard fdd8514, then work OK!

  • 2 Votes
    34 Posts

    Use pgrep/pkill! 😉

    kill -s USR1 $(fgrep -f "app.js")

    or even shorter with pkill

    pkill -USR1 -f "app.js"

    Substitute -USR1 with -SIGHUP and you got yourself a quick and easy build-tool command to restart NodeBB, when changing files. 🙂
    (I'm using SublimeText / Atom)

  • 1 Votes
    1 Posts

    Something that interested me when I first started hacking on NodeBB was how the platform uses realtime communication through (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".

    In 2011, I gave a talk at Keeping It Realtime conference in portland about some of my findings, you can watch it here: (long hair and all) or check out the slides here:

    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, 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.

    Refactoring this deep internal of NodeBB would make the platform more resource efficient on the wire, and also allow for better logging and handling of data. You'd know exactly what has failed on the client-side or server-side and be able to give an appropriate response. In the code, refactoring this level of things would make the code far cleaner, and give option to provide all HTTP Verbs over WebSocket or vica-verse (meaning if you wanted to, you could make 90% of NodeBB standard HTTP. You'd end up with an "api" module internally that is everything that can be exposed, which simple returns back standard javascript objects.

    For user-to-user chat messaging you could still multiplex that onto the same actual websocket / 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.

  • 3 Votes
    6 Posts

    This is a very interesting thread and I would love to see @xiehan's idea come into fruition. Going forward I believe more and more sites will add a forum feature to their already existing site rather than running it separately so a seamless integration becomes the more vital. @Xiehan I would also love to know what you guys have done to overcome some of these limitations?