How to modify node-red deploy operation to save flow to database

@kuema, do you know of any custom storage backend that saves to database already implemented? Perhaps it's already done?

Several, actually.

EDIT: Some of these are nodes, not storage backends!

1 Like

@dhpatel177 perhaps one of these will help?

Here's one for MongoDB, for example:

Can I ask why you want to save it to a database?

I think the goal is to get the multi-user approach mentioned in this very first post, each user getting their own flows:

Ok, thanks.

Why not use the file node to read flows.json put it through a change node and extract the tab you are looking for and store that in the database. (Roughly speaking)

Plus, use a Watch node to determine when the flows have changed so you know to update the database.

no - the correct way is as @kuema pointed out... to write your own Storage plugin to the provided storage API.

1 Like

Guys just found one way to call to external api using..............Thanks for your efforts @afelix @Steve-Mcl @kuema @Colin @bakman2

npm install axios

add in packag.json - "axios": "0.19.2"

In js file :- var axios = require( "axios" );'http://localhost:65305/api/v1/flow', {
        flowName: "test 2",
        flowData: "test 4",
        userId: "3fa85f64-5717-4562-b3fc-2c963f66afa6",
        solutionId: "3fa85f64-5717-4562-b3fc-2c963f66afa6"
      .then(function (response) {
      .catch(function (error) {

That is the correct way, by one definition of the word correct, but as many people would not have the knowledge to do that an alternative crude method may be more appropriate.

I'd rather implement a well-documented API than poking and muddling around in the core code I know nothing about, and possible break other things along the way. :smile:


I think it depends on the use case. The first created topic mentions this as a requirement for an application/project. If this would be rolled out, the environment in which it happens might play a role too. Some go for a custom version of node-RED to solve specific domain level issues they run into or embed requirements for their own use case. Others can do with a generic solution through a storage plugin that integrates with the unmodified core. Making modifications to the core means you can’t easily upgrade without merging all upstream changes back into your fork, assuming you make a fork first. Whilst through a storage plugin unless there are breaking changes you can easily update. But if you’ve changes needed beyond what a storage plugin, or say a middleware elsewhere, can solve, sometimes forking and modifying the core is your best option.

1 Like

Isnt this just gonna get broken everytime node-red is updated?

I feel it would be better to use the Storage API mechanism @kuema pointed out here


I'd even prefer the solution @bakman2 and @Colin presented, by watching the file from within a flow and send it to that API. Nice and clean.

I don't see any reasonable need to modify the core code for this API call.

so this flow is watching itself ? Fine until someone deletes that part of the flow.
If the end goal really is to do something multi-user (as per How to modify node-red deploy operation to save flow to database) then using the API is the correct way forward.
Unless the users are people you can afford to upset.

1 Like

That watcher could run in a separate Node-RED instance solely for that purpose. :sweat_smile:

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.