I'm considering use of NR as a graphical programming component inside a larger project, to allow end users to more easily maintain some of their own logic/code/rules.
However, we would need to support versioned flows, where all prior versions were still deployed and accessible. Access to run a versioned flow would be through an http REST/JSON post, with the version of the flow that should be executed included in the payload. We need to be able invoke prior versions against historical data. This would also facilitate testing, since the we could run a new version and compare results against a run of an old version. I could see this also being useful if you were supporting a larger network of IOT devices, where some older ones needed a prior version of a flow.
Ideally, the versioned flows would be stored in a database (ie. MongoDB), and would load at NR startup.
Trying to avoid having to determine and run the version to run manually in a parent flow. We would like to save a new version of a flow to the database, tell the NR server to reload and have all versions in the dbms be loaded dynamically.
I suppose we could dynamically generate a parent "version selector" flow from the database information, building the parent JSON using a code generator.
This node: node-red-contrib-flowman looks like it might help to accomplish a lot of what we're looking for. Can anyone confirm if it works with the latest 1.0 NR version?
Has anyone tried to do something like this? Any existing nodes that might help accomplish this both from a versioning and dbms storage of flow json definitions perspectives?
The flowman node hasn't been updated for almost a year, not the sort of thing I would trust for a production environment. I'm sure you will get answers to your problem in due course.
I am actually developing my own 'audit' flow process, to keep deployed flows to remote devices consistent with the official version of said flows, I keep in a central repo. My working idea is just track the flow tab name, any version # included in that name, say like "Flow A 1.0" or "Flow B 2.0" for example.
The local audit flow watches the flows*.json file for updates/changes, then does a simple check sum parsing the flows*.json file in the ~/.node-red directory, as an extra check with the tab name and version #.
The local audit flow sends applicable information to a DB, and a 'monitor' auditor flow does the comparison and reporting as applicable.
This idea is not a backup and restore solution, just an audit tool. Of course I could send the flow content to the DB as well, but as I noted, there are issues because such is not a complete backup.
