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.
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.
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 have a question about best practice for caching.
I have a CMS system outside of nodebb. It generates header HTML that I need to import into nodebb.
This needs to be rechecked periodically because the CMS build is using cache busting hash URLs, so urls to things like image and css assets will always change, as in /imgs/foo-XYZHASH.jpg. Outside of that problem, the header is already being served on a URL by itself, like mysite.com/header.html
I'm imagining the least painful way to do this is to fetch() the HTML in a nodebb widget or template, cache it, and recheck it periodically.
Is there any precedent for this kind of pattern? I've read about @baris's work https://community.nodebb.org/topic/17136/caches-used-in-nodebb but I'm still not sure how this should all fit together.
Thanks for any guidance.
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.
One obvious ChatGPT use case is summarizing an entire thread. It's very simple with most of the LLM APIs.
It would just need to be run when the thread has changed significantly โย there's some probably some nuance on that front.
@BrotherGlaucon did you publish your Dockerfiles and configs anywhere? I just started looking at fly.io for nodebb.
why not prefix files in a user dir? /assets/$user-id/