I highly appreciate the valuable input about hosting from all of you, but I feel this discussion drifting away from the original question quicky
Is archiving content so far out of scope or dispensable for the project?

@AOKP You might be right about that - we went from a managed hosting provider to DO when the market was small, I've never bothered to compare again since then. My location is no secret, I'm from Germany, the board's here. I'd be thankful if you could share some good providers having data centers in or near germany!
I'll set up a testing environment with NodeBB and SSDB, thanks for that one!

Redis allocates around 2.6GB real memory currently, hinting to NodeBB consuming most memory for posts (or I'm doing something horribly wrong). @PitaJ on a general note, does the way NodeBB handles keys in the db have potential for optimization? Because most applications do

@PitaJ :
I'd like to stay with Redis - it's a battle-tested, hugely scalable and ridiculously performant key-value storage. No matter what happens in the future, Redis will grow with it.
The responsiveness is perfectly fine, we've got four cores dedicated to nginx and NodeBB, that works well. But I think it would be a nice addition to NodeBB to be able to not hold less frequently accessed content in memory but load it on demand. I'd imagine that'll be also interesting for huge-scale instances.

@AOKP :
I'm currently using DigitalOcean, yes, because I like VPS servers. I'm a fulltime sysadmin, many of my work clients have their own datacenter servers, so I'm aware there are cheaper possibilites. Though I think the huge advantage of a virtual box is the speed to scale it, and the direct control over its power supply and console.

I've just looked at SSDB, but I wonder what the main advantage is? The stats seem to indicate it is a little bit slower than Redis, but funnily enough the page doesn't list any selling points... Less memory consumption?
I could clean the database up, but to be honest, while I'm the admin and responsible for the server, I'm not really involved with the content or its users.

For the stats, here you go:
Keys in Redis: 2,402,609
Posts: 193,060
Users: 2,257
Topics: 7,740
Page views per week: 549,187
Uploaded files: ~4GB

Hey there!
Several years ago, we started our board on MyBB. We migrated to NodeBB v0.3 as it started to get crowded, and have been happy ever since. The db server it's Redis instance is running on has 4GB of RAM currently, off which around 70% are in constant use.
As the consumption continues to grow, I know we'll have to upgrade the server rather sooner than later, and that made me wonder how to solve this without keeping to throw memory upgrades on it.

My idea would be to swap older content (configurable threshold) from Redis into a MongoDB instance, for example - it shouldn't be a problem to create different adapters, let's say MySQL or even JSON for a pure disk solution.
If there was an algorithm checking the popularity of content, it would also be possible to not just stupidly moving old content but less frequently accessed content to the archive.
To be clear: I'm not talking about caching here, since that would imply keeping the content in the Redis store.

Since this would require setting up multiple database systems, it shouldn't be mandatory (there surely are many users who can just use machines powerful enough and keep sizing them, but that doesn't apply for everyone).

Would this be feasible? Is it on some roadmap already, maybe? What's your opinion on this?

@teh_g sadly, this won't be possible with Electron, since it requires V8, Chromium and Node.JS to run, all of which are not available on neither iOS nor Android.
You could maybe use Cordova for this, but it would require a C# developer, store licenses etc... not forget a great amount of time and effort.

Electron, on the other hand, makes developing Desktop applications with JS easy and really quick... So it would be quite easy to craft a NodeBB client. I imagine board admins could run an installer like npm install nodebb-electron-client-setup, then do npm setup and have the client available for download at http://example.tld/client/:os for their users.

I'm currently using Electron to build a desktop client for an Express app which just transforms API JSON responses into views.

Now I was thinking it would be great to have a boilerplate, customizable NodeBB client built with Electron. It could be customized to fit the board style, use real OS notifications, open chats in real modal windows, integrate better file browsing and upload and so on. I bet gaming board developers would also be pleased to have native Steam integration etc.

Would anyone be interested in building such a client together?

@Moritz-Friedrich solved it somehow ugly by starting the tests in a "ready" callback. Is there some way to find out whether downloaded code has been fully executed?

I'm testing my client side code using mocha and I'm having a problem I can't really wrap my head around...
The script downloads its dependencies from the server itself. As long as I clear my cache and reload the page, my tests work fine. When I reload the page normally, though, they fail. If anyone is interested, the code is currently online here.

@julian

I like NodeBB's source, though it would be nice to have real documentation for it Maybe even something like consistent JSDoc comments?
Thank you for the kind words, by the way. I'll keep updating this post from time to time

@frissdiegurke I stumbled across it while searching one for a project at work, liked it very much and contributed some needed patches..
I rather meant using NodeBBs login system there, that should not be that much of a hassle.

It might be easier to integrate Raneto with nodeBB

@faddat Repo is up (https://github.com/Radiergummi/Node-Penny-Auctions), can't guarantee it'll run on another machine straight away.
Considering cryptocurrency, I purposely sticked to "paymentUnits" everywhere I dealt with money, as I'd like to seperate payment and bidding, so things like Bitcoin should be not much more of a hassle than PayPal or credit cards.

Please bear with me, I'm no industry professional yet. You'll find a huge bunch of flaws in there, but that will definitely change once I get the thing running more or less stable.

Hey there!
I'm currently building an open source penny auction site. Since I like NodeBB and the way its code is structured, I reused some parts (templates.js, socket io, the way middleware, routes and controllers work) and it works pretty well so far.

If anyone would be interested in developing for fun, I'd be happy to share the codebase on GitHub. It's an interesting project so far that I've learnt a ton of stuff from, and there's still a bazillion things left to do.

Some screenshots from the Admin panel (front-end is german, but that'll change once I figured a way to make translation work smoothly):

I noticed that whenever I reload nodebb, I get error messages like this one in the log:

31/7 23:47 [12036] - error:  Error: Failed to lookup view "500" in views directory "/var/www/node/nodebb/public/templates"
    at EventEmitter.render (/var/www/node/nodebb/node_modules/express/lib/application.js:579:17)
    at ServerResponse.render (/var/www/node/nodebb/node_modules/express/lib/response.js:961:7)
    at ServerResponse.res.render (/var/www/node/nodebb/src/middleware/middleware.js:337:10)
    at /var/www/node/nodebb/src/routes/index.js:223:9
    at /var/www/node/nodebb/src/middleware/middleware.js:192:12
    at /var/www/node/nodebb/node_modules/async/lib/async.js:589:17
    at done (/var/www/node/nodebb/node_modules/async/lib/async.js:126:15)
    at /var/www/node/nodebb/node_modules/async/lib/async.js:32:16
    at /var/www/node/nodebb/node_modules/async/lib/async.js:586:21
    at /var/www/node/nodebb/node_modules/templates.js/lib/templates.js:160:12
Error: Failed to lookup view "500" in views directory "/var/www/node/nodebb/public/templates"
    at EventEmitter.render (/var/www/node/nodebb/node_modules/express/lib/application.js:579:17)
    at ServerResponse.render (/var/www/node/nodebb/node_modules/express/lib/response.js:961:7)
    at ServerResponse.res.render (/var/www/node/nodebb/src/middleware/middleware.js:337:10)
    at /var/www/node/nodebb/src/routes/index.js:223:9
    at /var/www/node/nodebb/src/middleware/middleware.js:192:12
    at /var/www/node/nodebb/node_modules/async/lib/async.js:589:17
    at done (/var/www/node/nodebb/node_modules/async/lib/async.js:126:15)
    at /var/www/node/nodebb/node_modules/async/lib/async.js:32:16
    at /var/www/node/nodebb/node_modules/async/lib/async.js:586:21
    at /var/www/node/nodebb/node_modules/templates.js/lib/templates.js:160:12

I think it is users trying to access the page while reloading, but it made me wonder if there is a way to prevent this from happening? Also, I have currently three worker threads enabled. Shouldn't they be restarted successively so every request can be handled?

@julian, here it is. Thank you for your time!

@julian Thanks, that works well! Though I still wonder why I cannot use my theme js... I took the skeleton for my theme for lavender and changed the name everywhere.. Have I forgot something?

I could hardly restrain myself from biting into my desk out of frustration yesterday, trying to use Masonry on a custom page. My theme script file (nodebb-theme-themename/static/lib/themename.js) is correctly listed in plugin.json but not included in the minified nodebb.js.
On the other hand (which is what troubled me), when I tried to include a script in the page itself that loads Masonry from a CDN and just initializes a masonry object, it kept being undefined.

So maybe someone can tell me what is wrong here:

$().ready(function(){
$.getScript("https://cdnjs.cloudflare.com/ajax/libs/masonry/3.3.0/masonry.pkgd.js", function(){ console.log('Script has been successfully loaded!'); });
var masonryTest = new Masonry(); 
});

that just gives

// Uncaught ReferenceError: Masonry is not defined
// (anonymous function) @ VM162:2
// InjectedScript._evaluateOn @ VM117:883
// InjectedScript._evaluateAndWrap @ VM117:816
// InjectedScript.evaluate @ VM117:682

Go ahead, try it yourself in the console at my site.
I have the feeling I overlook the obvious...

@hek said:

Node.js is very efficient due to it's non-blocking asynchronous nature. It beats PHP every day.

Not arguing on that. Comparing NodeBB to the previous MyBB PHP-based board though, I can see that the community simply consumes much more resources than before and becomes slower the more requests are coming in. I never experienced a slowdown of multiple seconds when using MyBB.
I mean I love NodeBB, it is a question of sufficient hardware though.

@Astralis-Lux take a look at Flarum, that's what I had on my list first... That may work better

It is not necessarily a redis issue but more due to the way Node.js works - after all, my guess is, for large forums, you may be better off using a PHP solution, unless you want to invest in a setup like, one load balancer, two to four db servers, four to eight app servers serving nodebb, one mailserver, one for firewall and security, a development box, ... you see where this is going