Re-purpose the flow editor for other flow-like data editing


#1

Guys,

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?

Thanks,
Yeling


#2

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.


#3

Thanks a lot.

Guess I will play with it for now and wait for the official release of separated editor and runtime.

Yeling


#4

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


#5

To confirm, is this going to be in the next release this month or will it be in the release after that?


#6

It is not in the next release, 0.19.

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.