It's an optimization, an opportunity to handle more traffic on less hardware.

Nodebb is using express for the API, right?

hyper-express

High performance Node.js webserver with a simple-to-use API powered by uWebsockets.js under the hood.. Latest version: 6.17.3, last published: 16 days ago. Start using hyper-express in your project by running `npm i hyper-express`. There are 18 other projects in the npm registry using hyper-express.

npm (www.npmjs.com)

My company just did some performance testing for our own API, and this package blew express away. It was a drop-in replacement for us.

why not prefix files in a user dir? /assets/$user-id/

Thanks @phenomlab

@julian said in User journal:

I think the idea behind a user journal is that it doesn't necessarily fit within the pre-defined categories in the forum, so you post it in your own personal bucket of... stuff?

I think that's right, imagine a health forum that wanted to give someone a journal space to track their progress with notes and photos. Or house remodeling. Or your works in an art school. Or anything else time bound or progress oriented. In these cases, I would expect: 1. at least one canonical thread for each user that was discoverable in their profile, 2. they have control over visibility, 3. they are the only one posting content there, by default.

This use case is also interesting to me because I don't think most other products are doing a good job at it, and nodebb already has all of the UX/I to do this well.

I guess the other way to do this would be to have one topic per entry, which might be better with use cases like allowing others to comment on every entry?

Thanks @phenomlab, trying to figure out how that works, it seems like an internal link organizer? Will look into it more.

Yeah that's closer, blog is just a loaded term, and your UI is highly specialized

@julian thanks for that background.

I'm not sure "blog" would be the ideal way to frame this since that's commonly understood as something more like substack or lifestyle recipe sites, typically articles and pages.

Maybe a nodebb differentiation or at least the use case I'm describing is more like a time-ordered scratchpad or journal, where entries can be one sentence, or just photos, or daily updates, or really anything depending on the purpose of the parental forum. Users can then scrub up and down through their progress. You guys have done all the hard work with the infrastructure/ UI already, this seems like a small tweak to extract an entirely new use case on the same foundation.

I'm thinking users would have a section on their own profile to access their topic, and likewise for finding other user's journals.

@eeeee topics are inherently useful because they have freeform content ordered by date, so there can be a lot of use cases here. If the topic is only writeable by that user but viewable by anyone (or private), it can be used to share anything time bound, like a journal, blog posts, progress in a goal, etc.

Does a user journal plugin exist anywhere?

Everyone would have one thread for themselves.

It would be pre-created by default.

Others could view it but not post in it. (maybe an option to make it private on a per-user basis)

Surprised this doesn't exist, I've looked into different options around this a few times.

(posted this in the wrong place previously)

Well said @razibal – the rewrite could also be staged in with utility classes like a nodebb sdk, then redux, then hooks, then React jsx, etc. so that the top layer could be swapped out to do something like power react-native apps. As you said, with a modern FE, deploys could be served entirely by vendors like Netlify and you would get modern features like fast builds, branch deploys, partial hydration, etc, piggybacking off many years of build and serve tech. Astro's offerings are a good starting point for vendors here.

The react and react-like stack won the war, there's an entire generation of developers that could turn their attention to nodebb for the first time. I would bet that nodebb's commercial offering would soar to host the server monoliths, especially if they rethink the pricing structure away from "page views".

Also the fact that there are so many solutions in the react ecosystem to power each one of these parts, there's almost nothing that would need to be written from scratch, from theming systems to admin ui, on out. That being said, the thread @The-SkyFoxx posted and the current fediverse work being done suggest this has no reasonable chance of happening, the developers seem oriented toward very different goals.

I was excited about this until I saw the date

I'm having a hard time with the brittleness of this templating and build system, it would be nice to see it decoupled further from the back end and brought into a modern FE stack.

Thanks, it looks like this is the fix:

tls: {},

making this the final object:

nodebb-1  | {
nodebb-1  |   host: '...',
nodebb-1  |   port: ...,
nodebb-1  |   username: '...',
nodebb-1  |   password: '...',
nodebb-1  |   db: 0,
nodebb-1  |   tls: {}

Is there any way to get that object through with the current version?

I guess this:

    "session_store": {
        "name": "...",
        "host": "...",
        "password": "...",
        "port": ...,
        "database": "0",
	"options": {
            "username": "...",
	    "tls": {}
	}
    },

Thanks but didn't work. Put a console.log on that line to make sure everything was correct:

nodebb-1 | {
nodebb-1 | host: '...',
nodebb-1 | port: ...,
nodebb-1 | username: '...',
nodebb-1 | password: '...',
nodebb-1 | db: '0',
nodebb-1 | }

nodebb-1 | error: MaxRetriesPerRequestError: Reached the max retries per request limit (which is 20). Refer to "maxRetriesPerRequest" option for details.

Also reverified that the same details connect in another client, they do.

I'm trying to use redis for session_store, but can't connect for some reason. I've verified that this server works with database clients and the port is open. It seems like when user/pass comes into the picture, nodebb fails?

   "session_store": {
        "name": "redis",
        "host": "$REDIS_HOST",
        "password": "$REDIS_PASS",
        "port": "$REDIS_PORT",
        "username": "$REDIS_USER",
        "database": "0"
    },

The docs seem to suggest this is correct:

session_store This is an object similar to the redis, mongo or postgres block. It defines a database to use for sessions. For example by setting this to a different redis instance you can separate your data and sessions into two different redis instances.
name (Name of database to use redis, mongo or postgres)
other settings are identical to the database block for the datastore.

and this configuration worked when I setup a localhost server:

   "session_store": {
        "name": "redis",
        "host": "$REDIS_HOST",
        "port": "$REDIS_PORT",
        "database": "0"
    },

Can anyone verify that the first configuration block is valid and functional somewhere?

It was showing successful builds in the pretty-printed list (sorry, I lost the screen),

then I believe this is the minification step, the webpack step, was failing based on not finding different node_modules, which turned out to be child modules like highlight.js, which are included by other packages. The child modules are apparently implicitly required and then included in client scripts.

pnpm, which I'm using, nests its modules by default, as in:

node_modules/parent_module/node_module/child_module

so all of the child modules need to be hoisted by putting this in .npmrc

node-linker=hoisted

so now the node_modules tree is

node_modules/parent_module
node_module/child_module

Why this wasn't triggered before, I have no idea.

My last question now is how can I ensure that the build exits with a failure code in any cases like this? This may have all been designed with prioritizing getting the server back up, but this is not ideal behavior for builds like docker, where it only replaces the running instance when the new instance builds correctly.

I'm probably going to put in something terrible like this into Dockerfile, but this is pretty hacky:

RUN for file in admin.min.js etc etc; do \
    if [ ! -f "$file" ]; then \
        echo "$file not found!" && exit 1; \
    fi; \
done

In Docker, I upgraded to v3.6.7, rebuilt everything, and admin is broken.

The error in console is that "Uncaught ReferenceError: $ is not defined"

Looking at the network panel, /assets/admin.min.js is not found.

In what conditions would this happen?

I'm debugging the build but it seems like the build should emit failure states instead of ploughing forward despite critical assets not being created.

Yeah thanks guys, the key was copying the package.json file out of the install folder (copying, not moving, because install/package.json is then checked during build). Now everything can be installed in one command.

I'm having trouble understanding what the point of this code is:

NodeBB/src/cli/index.js at 16f0affa701fbc1b89745386d709c39179caca24 · NodeBB/NodeBB

Node.js based forum software built for the modern web - NodeBB/src/cli/index.js at 16f0affa701fbc1b89745386d709c39179caca24 · NodeBB/NodeBB

GitHub (github.com)

if (['ENOENT', 'DEP_WRONG_VERSION', 'MODULE_NOT_FOUND'].includes(e.code)) {
		console.warn('Dependencies outdated or not yet installed.');
		console.log('Installing them now...\n');
		packageInstall.updatePackageFile();
		packageInstall.preserveExtraneousPlugins();
		packageInstall.installAll();

It runs even if it's preceded by an npm install, so I'm not sure what problem it's finding. It's slowing down docker builds by quite a bit. The other issue is that if you use a faster package manager like pnpm, it's still piping everything through npm.

It would be nice if:

1. there was a flag to disable this behavior for environments like Docker
2. the package error is output with console.debug so there were some chance to solve the problem. I'm finding nodebb's internals a bit mysterious based on behavior like not surfacing errors, which is making debugging a lot harder.

As in client side fetch? This is critical HTML that would block renders so that would be pretty bad. It's the header and has some search functionality in it, for example.

On the other hand, if there was something like a remote-html convention for the widgets that fetched on server and expired the cache automatically, never blocked render, etc... that would be cool but I'm not sure how or where to see how caching works in these kind of cases.