Continuous/reactive deployment on node creation

General
1

I understand that when you create a new node, then you press "deploy" to generate the workflow and run it. But, is it possible to make a reactive workflow where the options (template) of one custom node depends on the previous nodes even if you didn't press "deploy" ?

For instance, I imagine a injection node that prompts a json with two values and you connect it to a custom node. Without pressing "deploy", the configuration template of the custom node will now have a drop-down where you choose among the provided possibilities.

I can imagine how to do this using context variables and making constant "deploys", but the fact of pressing "deploy" will kill the reactivity. Another possible solution would be a node that executes code in his configuration stage (before deployment), not sure if this can be done.

I guess a possible answer could be to make a custom UI or use node-red UI builder with a reactive js framework, but I just wanted to know what is the easier way to do a reactive workflow, or if this is even possible within this framework.

2

I don't believe this would be possible. The Deploy button commits changes made in the Editor to the runtime. Those two things are deliberately separate.

I think that the nearest I've seen to something like that would the cron+ node which has the ability to create a schedule via an inbound msg. You can then view any schedules I think.

But it isn't the standard way of working with Node-RED. Nodes are not meant to have to know about their upstream or downstream neighbours, that is one of the fundamentals of how Node-RED works. Each node is largely independent and is triggered by an inbound msg. Shared information is generally either via a config node or a global/flow variable. Changes to configuration and flows are deployed to the runtime.

This would be a better approach I think since it doesn't involve changing the fundamentals of Node-RED. Such a custom UI would still be sending messages back to node-red though for a flow to process and so would still need mechanisms to retain the data in case Node-RED is restarted. But that's OK, because there are certainly methods for doing that.

I think that it would be easier if you described what you actually want to do in a bit more detail so that people can help steer you towards a workable solution.

1 Like
3

Ok, Many thanks for your detailed response!

I will try to explain the use case a bit better. What I'm trying to do is a data-workflow where the datatype (which comes from a http request, that we can't control) may change and the user needs to change some datatype constrains quickly in the workflow.

For example I receive (using a http request) a json dictionary with two elements {"col1": [1,2,3], "col2": ["a", "b", "c"]}, I connect it to a custom-node (check_type_node) that checks that col1 contain only integers and col2 contain only string.

Then, by external (no controllable) reasons, the order is subverted and we get {"random name": [1,2,3], "col1": ["a", "b", "c"]}, the check fails raising an error and we need to quickly change the setting on the custom node to check that "random name" is a integer and "col1" is a string.

Even if the datatype never changes, It would be fantastic that the own node in the editor will let you choose among the variables received, because otherwise you will need to go to look them and write by hand the names on the setting. But is even more important, as the datatype changes from time to time, so the workflow is never fully static and defined, rather changing as the datatype changes. The aim is to make the configuration of the check node extremely fast because it will be already pre-templated using upstream nodes.

Seeing your answer I understand that that wouldn't be the way of working with Node-Red, but I thought I could find a work around, as making a new UI or even I was also thinking that setting global variables at the browser session/node-red server could be a possible solution, if they are latter watched reactively by the custom nodes, but not even sure if that is possible, or how to do it.

4

So you could go to the effort of building a flow (or custom node) that permits runtime settings entry making your flow dynamically programmable via some JSON or other type custom settings - GREAT

BUT

  1. You lose the graphical / visual representation & hide things in a complex custom parser that you cannot hope to debug

  2. Is the effort involved in achieving this actually worth the effort when you can AT RUNTIME & without stopping exiting flows (so long as you use single node deploy method)...

    • add a new flow TAB dedicated to handling this new format data - deploy
      • test it with an inject & debug node
      • once its working, connect a link node and link return node (i.e. make it into a subroutine)
    • adjust the routing SWITCH node to direct these new style messages to the new subroutine
1 Like
5

I think that what you want could be achieved. The trick would likely be capturing some suitable datatype/data patterns so that you could keep records and only create new records for new patterns.

None of that requires a dynamic, changing flow but rather, careful management of the data patterns.

I see that Steve has also chipped in with another way and that is also achievable and indeed simpler than what I was thinking of as long as you also tidy up occasionally since I could see the whole thing getting out of hand if you weren't careful.

6

That was interesting, thanks both, for your comments! :slight_smile:

Unfortunately, the reactivity I try to archive is almost a hard constrain for the flow, as potential users could be completely unaware of how node-red works, but they will still need to adapt it, making the adaptation of the nodes as easy as possible is therefore really important, on the other hand, I don't really expect to find patterns in the received data.

So I guess I will try to add "runtime settings" entries in the flow as Steve describes. If any of you could describe a bit better how would that look like, or provide any link describing these setting I would be grateful, as my knowledge on the topic is still limited. These runtime settings are the same concept to the ones used for authentication or theme? like in this link configuration node red or will they be a completely new concept?

In any case I think your (Steve) idea is already close to the solution and I'm trying to figure it out, how can I make it work. Thanks again :smiley:

7

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