NodeBB Assets - Object Storage

phenomlab

@baris @julian I think this should be made into a plugin if I'm honest. Obviously, there are other steps that need to be completed outside of just installing the plugin, but this works very well, and it's extremely fast in my testing within dev.

razibal

@phenomlab said in NodeBB Assets - Object Storage:

This has a lot of potential using workers and R2, and really needs proper documentation. As you know, it's taken me 4 hours to get this working!

Yeah, it only took me a few minutes to get it working as a POC this morning, but , as you experienced, getting that even partially operationalized took a lot longer.

The nice thing about implementing this is that it makes nodeBB essentially infinitely scalable. All static assets are handled by cloudflare workers while the nodeBB API can be deployed to droplets behind a load balancer. Spin up droplets as demand increases and then spin them back down when no longer needed.

phenomlab

@razibal this can probably also be extended to services outside of Cloudflare and AWS.

<baris>

What would go in the nodebb plugin? Seems like all the instructions here are happening outside of nodebb source code, like making a post build script to copy the built assets and the script that runs on cloudflare.

phenomlab

@baris correct, but those lesser conversant could make use of a plugin that completes the NodeBB side.

razibal

@phenomlab said in NodeBB Assets - Object Storage:

@razibal this can probably also be extended to services outside of Cloudflare and AWS.

Thats correct, this would work with any CDN that provides object storage and a mechanism to proxy a path like /assets via cloud workers or CDN proxy service

phenomlab

I thought I'd come back here and post my findings with this so far. My DEV instance is using R2 along with CF workers, and works as expected. Speed is very good.

The production environment uses the traditional method or serving critical assets on site access, but also uses Redis and 3 NodeBB processes (clustering). There is no discernible difference in the speed of the two environments which I find both pleasing, and yet surprising!

I'm performing more tests, and will provide an update here.

razibal

I was also able to validate the concept of spinning up multiple droplets that mount the same build as the master by mounting the assets using s3fs

nodebb-static:assets on /data/nodebb/nodebb.s3/public type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000,default_permissions)
nodebb-static:assets on /data/nodebb/nodebb.s3/build/public type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000,default_permissions)

phenomlab

@razibal I am not seeing any evidence of the postbuild.js script running after a standard ./nodebb build (unless there is no output?)

razibal

@phenomlab the postbuild script will only run when you execute ./nodebb build via npm run build as that has the logic to execute the postbuild step. The postbuild script should probably be modified to only sync the build/public folder after the initial sync. There should be no need to sync public with every build unless the version of nodebb changes. All new uploads would already be stored in the S3/R2 bucket by the s3 upload plugin.

So a npm run build init for the initial sync that includes all static assets, and then just npm run build that only syncs the rebuilt assets such as templates , plugins etc.