react-redux-nodebb, we are building it!
-
@data-dataninja how is this effort going?
-
@o-o Agreed, much as I love nodeBB I would love to see the UI decoupled from the API services. To be fair, the existing nodeBB architecture is already structured to allow for this. The only missing piece is a statically hostable front end written in Next.js (or Nuxt, Astro etc). I would especially like this as it would make nodeBB embeddable as a "forums as a service" provider without having to resort to subdomains or embedding in iframes. I imagine that the vast majority of nodeBB (and forum software in general) are using it as an adjunct to existing websites, and this would instantly make nodeBB a much more attractive option compared to the competition.
-
@razibal You may have a point about the templating system not being optimal (I had one issue where js code in a widget was replaced, as it matched symbols the templating system).
However you mention Next.js as an alternative - did you ever code any project in Next.js? I had such a horrible experience with it. I can't put into words how awful it can be, even experienced Next.js coders have endless issues from what Ive read in the help groups. Of these alternative frameworks SvelteKit has more favourable feedbacks.
There are a few competing frameworks, they are 'maturing' so maybe in time there may be a debate over benefits of one of them, but it doesn't appear that time is yet. -
@eeeee I wasn't suggesting that the nodeBB team select Next.js, that choice should be based on whatever framework works best for nodeBB based on the choices available. My point is simply that the UI should be a separate component and not married to a nodeBB monolith.
BTW, I have used Next.js and it wouldn't be my personal choice for a new project. However, it has, by far, the largest installed base of production apps and if the goal is to appeal to the largest set of potential users of forum software, it would be an easy front runner for the "default" front end UI.
Keep in mind, that if the nodeBB team decides to go down this route, the front end
UI essentially becomes the equivalent of the current concept of themes. This allows anyone to use their framework of choice in their own implementation. -
@razibal said in react-redux-nodebb, we are building it!:
UI decoupled from the API services.
That would be amazing, but I imagine there would be some problems to solve, such as theming and websockets.
But I believe NodeBB decided not to pursue this path at least in the short term:
NodeBB + ReactJS
To give you a little bit of history... @youhosi -- no, we explicitly made the decision to not use a framework for our frontend because we as developers were ...
NodeBB Community (community.nodebb.org)
-
@The-SkyFoxx Decoupling the UI and choosing a framework are two separate architectural choices and not tied to each other. You can decouple the existing UI from the backend without rewriting the existing core or moving away from jQuery or breaking any existing functionality such as themes and client-side plugins.
At its most simplistic, it would be simply 2 express servers, one for hosting the client JS and static assets, while the second would be for the API services and authentication/session management. The UI express server could also be compiled to statically hosted javascript that would no longer need an express server and could be served from S3 buckets. This is easy enough to do for express based apps. The benefits of this approach are quite worthwhile. As the previous posts suggested, it allows for separate lifecycles for the UI and the core API services. It should also boost performance substantially as all static resources including the UI would be served from S3 buckets.
Optionally, the standalone API server now freed from hosting the UI, could be moved to an API server better optimized for pure API services such as fastify. You can lookup the various benchmarks, but Fastify or Restify are anywhere from 3X- 5X faster than express for API requests.
Lastly, I would also decouple the session management, but that's a "nice to have" that would let nodeBB be a truly serverless application that could run entirely on the cloud and be essentially endlessly scalable. -
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.
-
@data-dataninja said in react-redux-nodebb, we are building it!:
We are building react-redux-nodebb
this will enable react-dom & react-native with nodebb, which means we can build nodeBB into native apps & also use react ecosystem UI components
steps we are taking:
- react-redux structure (state, api, hooks)
- converting controllers
- module bridge (to enable current ecosystem of plugins)
then next up we will build:
react-native-nodebb theme & skinsAny help & suggestions are super welcome!
This is quite an old post, but @data-dataninja have you given up on building the decoupled frontend?
I am more interested in a NextJS or any Server Side rendered solution to get the SEO and other benefits of SSR.
But a frontend in React-Redux would be a good start if you're working on it.
