A few years ago there was a discussion here about using Node-RED as a CMS.
I think the more interesting question is slightly different: is Node-RED a good platform for building process-driven web applications?
I've been using it this way for some time now, including our company's public website and an intervention-management web application, both running in a DMZ.
I use my own flows for user management and application structure, with Liquid templates for rendering, while Node-RED handles business logic, databases, APIs and workflows.
As a real-world example, the intervention-management application currently gets:
Personally, I wouldn't use Node-RED as a traditional CMS. But for complex web applications where the complexity lies in business processes and integrations, I find its flow-based model particularly well suited.
I'm curious how many others are using Node-RED this way, and how far you've taken it.
It was actually one of the first things I created with Node-RED: it was called RedBack - Node-Red as Backend and lead to one of my favourite comments here at the forum:
So it has the potential to get misundertstood when using a web application to create another web application, even if you think it's amazing to create a visual web application with Node-RED.
EDIT:
I continued on and my blog on Node-RED is running NR with the content actually being the flows, i.e., articles are flows, there is no database backend to store content.
For some time, I had been looking for a system that would let me handle devices communicating over different protocols such as Modbus, store the data in a database and visualize it all in one place.
Node-RED has worked very well for me in this role. Dashboard 2 did not really fit my needs, so I started building my own frontend module based on React.
At this point I already have more than a dozen different tabs and applications running in production and their use cases are quite different. Some are only used to visualize data from MSSQL, while others are based almost entirely on direct communication with devices. They read parameters, change setpoints, set temperatures and control parts of the process.
What I also like is how flexible this approach is. Today I need one feature, next week someone asks for another one and then something else needs to be changed. I just open the React editor inside the flow, make the changes and click Deploy.
With a typical standalone React application and a separate backend there is usually more involved. You need to build the application, create a new Docker image, replace the image, restart the container and so on. Of course this can all be automated, but in my case Node-RED simply gives me a much faster development and deployment cycle.
That is why it works so well for this kind of application. I do not really see Node-RED as a traditional CMS. For me it is more of a platform for building process driven applications where a large part of the logic is related to devices, databases, communication and control, and where requirements can change very quickly.
Well, that post is rather outdated now. Especially since UIBUILDER for Node-RED now includes a CMS feature - Markweb - allowing you to easily build a web site from a Markdown file structure.
I agree that this is a core potential for Node-RED. I tend to describe UIBUILDER as an extension to build "data-driven web apps". Node-RED provides the process, UIBUILDER takes the data and helps you create UI's with it.
UIBUILDER doesn't care whether you use a front-end framework or indeed a server-side templating engine. It works with and without. It provides the structure and tooling to make the communications easy. It allows you to use both Node-RED driven HTML creation and/or more traditional web development processes (useful for development teams already used to doing web apps).
I am somewhat wavering on this subject. I've done everything from creating my own custom CMS's through using platforms such as Wordpress through to static site creators such as Hugo and ASTRO.
A CMS typically is driven by content more than data and so needs somewhat different tooling. Markweb does the translation from static Markdown files and folders to HTML dynamically on the server so content management can be done very easily using standard tooling. It also however, enhances that with UIBUILDER dynamic features should you need/want them. Markweb is rather basic right now but it does build websites straight out of the box with no programming required at all. And no build steps either.
It doesn't have to be complex web applications. It can be simple ones too. But yes, a lot of my personal Node-RED use manages data and event processes and uses UIBUILDER to provide accessible UI's. I'm retired now, so I no longer use Node-RED professionally.
This is exactly why I build UIBUILDER over a decade ago and have been enhancing it ever since.
The only difference being that I long ago realised that with only a little help, vanilla HTML/CSS with some occasional JavaScript is generally more than sufficient for everything and while UIBUILDER originally focused on enhancing things with the help of VueJS, I quickly realised that these complex front-end frameworks just got in the way and added, sometimes extreme, overheads and restrictions. This also means that generally, no build steps are required for changes.
REACT may be useful for really complex solutions, especially where large teams of devs are involved but I'm seeing more and more web developers coming to the same conclusion that native HTML/CSS with some occasional JS can do everything we used to need a framework for.
