I get here while searching for an web based process flow editing tool. And I found it quite amazing.
I now understand Node-RED as a programming tool as well as flow execution runtime which are tightly integrated together.
My case here is that I don't want the execution part, we are not that into server side JS, yet. The execution part would be taken care of by other frameworks.
I saw some design notes about split the editor and runtime, but seems not done yet.
How much effort would it take if I want to take the editor out as a standalone tool?
We are working on splitting out the editor and runtime into separate packages and that will be coming fairly soon once we get the next release done this month.
If you created an alternative runtime that provided all the necessary admin end-points used by the editor, then you could repurpose it.
It really depends on just how custom you want it to be. I can't tell you how much effort it would be as I don't know what your specific requirements are... but it wouldn't be a simple task.
Yeling, I had the same question earlier this year -- how can I set up a node-red "Editor" for drawing process flows, without having a "server" runtime working behind the scenes...
Nick, please correct me if I'm wrong, but from what I understand, the first "deliverable" will be separated packaging for the editor and the runtime -- not usable applications and/or tooling that allow someone to execute the editor or server flow independently. Those will naturally follow, but the repackaging is needed first to allow this community to build those 3rd party applications and tools.
In the meantime, I believe I've found a simple and relatively non-invasive way to "disable" the runtime server (I know, I know -- why would anyone work to undo all the good stuff going on in the server?!? but that's what the customer needed).
Since I am already running my node-red instance behind an nginx reverse proxy, it was easy to "redirect" the internal http requests for retrieving/saving the content of the editor flows file. In my case, the /flows GET or POST request from the client-side Editor is proxied to an external web server, which handles the flow JSON string outside of node-red. This means that the runtime server never receives any updates to the flow contents. So essentially the runtime is always running, but it's working with an empty flow. This also means that two individuals running the same Editor instance in different browsers are not pushing updates to each other's editor session -- so if you need to have multiple users working on the same flow content, this may not be a solution for you.
The other potential solution is to replace the built-in storage implementation with your own. Check out the docs for the storage API -- you can also look at the current filesystem implementation that's included with node-red, or the bluemix version based on MongoDB. Although now that I think about it, that doesn't give you a no-op runtime... but there ya go
The plan is for the packaging split to be 0.20. But to reiterate, it is a packaging split - it isn't the creation of a stand alone Editor application. There will be no visible change to the end user. Whether the split then supports every single use case people have, I cannot say.
It has been about a year since this post and 0.20 is out. Any updates on the best way to repurpose the editor?
It still looks like when firing up the editor you need to supply a runtime and that the editor will return a 503 if it isn't started:
var ensureRuntimeStarted = function(req,res,next) {
runtimeAPI.isStarted().then( started => {
if (!started) {
log.error("Node-RED runtime not started");
res.status(503).send("Not started");
} else {
next()
}
})
}
I could fork and just return anyway, but I would imagine there is a better way...maybe forking the runtime api and stubbing it out as mentioned earlier.
Has anybody had succeed in repurposing the Node-RED Editor? I've also been looking around for web-based flow programming GUI. I have been fiddling with React Flow for a while, but it is too much work to add functionalities that Node-Red Editor already has, e.g. copy-paste multiple node; node drag-n-drop-n-insert between connector line.
Anybody has info about alternative of it (web-based flow programming GUI)? Any info would be really appreciated. Thanks.
Hello everyone,
we're also looking for an Editor different than Node-Red Editor, which creates a "node-red flow" in the standard json format. We need that because we don't want to start the whole node-red instance just for creating a flow (and not running it)
Do you know some alternative for the edition part ? (without using React Flow)
Not sure what the parameters of your question are... any editor capable of editing text can create json so in theory you could use vi or word or even these days chat-gpt, or whatever you like. All of which would be using some resources to run.
Hello dceejay
You're right, my last post was not precise at all:
We're looking for any similar kind of node-red editor, with nodal concept, that does not need a runtime-part like Node-Red still need (for now). In a perfect world, it would be the Node-Red Editor UI itself, as a static website (or library?) without any websocket features or need for the runtime.
As a workaround, I knew there was an attempt to have a node-red instance directly inside the browser (with the runtime) that would avoid us to spin a Node-Red instance server-side just for edition. I couldn't find it anymore.
Context: In our project, we have split (for good reasons) the creation-part of the flows, and the runtime-part of it. We use Node-Red for both, but because of the split, we need two instances of Node-Red. For the "Creation part", we just use the Node-Red UI to create the flow and "save" it in database (using an http api in runtime storage plugin). We want to avoid a specific instance of Node-Red for that (we use docker containers).
I hope this is more understandable now and not just more confusing...
You can run node-red in "stopped" mode (i.e. the flows are not running / not executing)
So in theory, you could have 2 instances. One that is stopped, the other that is running.
The problem with "just an editor" is that much of a nodes configuration comes from the node itself - therefore the node needs to be "installed" and the core of node-red needs to run in order to do the right thing. But as stated above, you can start node-red (and serve the editor) without the runtime executing.
Indeed, the Stop/Start will stop the runtime (we're using it), but it's still included and needed.
We're indeed looking for the "just an editor" way and I understand why it's not so simple
For us, node configurations are just simple html/json that can be given to the "simple" editor without needing a runtime to init or other processing (and I imagine it's the vast majority of nodes, except maybe for Config nodes)
