Trying NodeBB on Ubuntu

General Discussion

Suggested Topics


  • 0 Votes
    5 Posts
    216 Views

    EDIT: Oh, I was late...

    To answer in a bit of reverse order:
    @eeeee said in Keeping Nodebb running after power outage:

    Also is the above method better than using nodemon?

    It's not really doing the same thing as nodemon - the latter is mainly for watching file changes and restarting the application in that case. However, it's not tied to system init in any way, if the system restarts (eg. due to a power outage) it just dies in the process and you need to start it manually afterwards.
    Systemd is a software suite which includes the init system and service management, and it's used by majority of modern Linux distributions. The file here is a service unit definition for systemd, and since the same suite handles the init as well you can trivially configure the system to start your service on boot (this is what the systemctl enable command does)

    Systemd also has facilities for doing a lot of other things like timers, watching file paths, etc. but they're not as commonly used as services, so a common configuration might be to use a systemd service to run something like nodemon or PM2 instead of using the harder to configure built-in tools.

    On my server I just have the account I log in with. should I make another user?

    Nothing is stopping you from using the same user, there are some security advantages to separating services but it's not unique to running as a systemd service so it won't decrease your security compared to your current setup.

    Like why does this file need a link to the docs?

    It doesn't - it really is just for the sysadmin (in this instance you) to see a link when they're looking at the service and eg. want to debug something. If you feel you don't need it just leave it out - for units I write for myself I usually wouldn't add it, mostly since there wouldn't really be much relevant documentation - but since someone was already writing a pre-made unit file, why not include something nice that might be very occasionally helpful at a cost of just around 40 bytes of disk space being taken?

  • 14 Votes
    18 Posts
    14k Views

    I was installing using the guidance available here and ran into difficulties. I'll try again soon when I have time to troubleshoot and provide feedback. It seems the installation isn't as easy as Ghost was for me.

  • 0 Votes
    1 Posts
    808 Views

    Hi
    I m currently following these two links
    Configuring Database
    Setting Up NodeBB on Digital Ocean

    Is there anything else that I need to follow to host NodeBB on digital ocean with mongodb as database?
    I m reading through the NodeBB docs and following the links by order but was wondering is there anything else that I need to know about?
    And the digital ocean guide is 2 years old and wondering if there's changes in things that I m not aware of.

    Thank you 🙂

  • 0 Votes
    4 Posts
    2k Views

    @belstgut said:

    Not really sure what all the hype about mongodb/redis lately is, if you can use well tested sql databases.

    MongoDB is well tested too. But beyond being super stable, it is screaming fast - far faster than any relational database, it has amazing sharding properties, it speaks native JSON, it is getting a massive amount of active development, it is considered the native database for Node.js on which NodeBB is built and it scales like crazy.

    Now the big one.... when using Node... those "well tested sql databases" are not well tested. MongoDB is far more stable and tested than any of them and, in fact, lack of highly reliable drivers is a major issue for relational (what you call SQL) databases.

    So there are very, very good reasons to use NoSQL, especially MongoDB specifically. Speed, stability, battle tested, native, etc. I'm not actually clear on any upside to using a relational database here. Relationships are nice, but would they add any value at all in an online community infrastructure?

    Also, I should note, some online communities that we have dealt with have scaling issues specifically because they eschewed this advice and went with those "well tested" relational databases. Once they grew and got busy they were unable to keep pace and they bogged down and had to throw crazy amounts of money at keeping respectable performance when MongoDB or other similar datastore could have been faster for cheaper.