hi all.. i have been building some things in Node Red recently and its been going quite well.. i have limited software development knowledge though and as i have been progressing i have started to wonder about a few things... i thought id ask..
I have a flow which seems like its getting pretty big.. i would say maybe 60-70% of the canvas is full of nodes.. what are the limits on size and complexity of a flow ? my guess is my flow isn't as complex as many other projects but i am curious what would be considered "getting too big" ? i currently have around 250 nodes probably 400 or so link nodes.. i will probably need to add another 20-30% in order to finish what i'm trying to do.. i'm running on a RPI5 and so far it still feels responsive..
a few months back when i started i had even less knowledge and i now see things where i used 3-5 nodes which could be achieved in a single function node or at least consolidated into less nodes.. does using 4 or 5 nodes severely impact performance compared to achieving the same task in a single function ? or is it mainly just consuming visual space on the canvas ?
is there any tricks to re organize a single large flow into multiple sub flows ? or does it require manually changing everything one by one ? is there anyway to do "find and replace" which can scan all nodes and change references from flow contexts to global ? or is the only way manually ?
i have seen things which say using sub flows is better than one larger flow and if i could go back and start again i would have done that from the start but i didn't know how large things were going to get..
i have built the web interface using dashboard 1.0.. i've noticed there are dashboard 2.0 nodes also.. is there any drawback to continuing to use dashboard 1.0, will it stop working in browsers anytime soon ?
Do you have any duplicate functions or duplicate flows that you could feasibly reduce to a subroutine? If yes, then using link-call is the better option.
You can select items to make into a subflow and "convert" to subflow. however, all you are doing is hiding nodes (and actually adding complexity) - unless the flow is stateful AND is a duplicate, there is little benefit to subflows.
A better way of organising would be to split sections with link nodes and put them on other tabs. there is a quick action for this (rightclick, split with link nodes)
Not really much benefit either way. However, if you reduce 100 of these situations, your flow file will be smaller and the browser will be more responsive. Processing wise, at the core, not much difference.
Soon? possibly not, but some day yes. Also, it is very old tech under the hood. If you can switch, i would recommend it.
if i put some sections of the flow on link nodes and place them on other tabs is that still considered the same flow ? i was under the impression a different tab represented a sub flow ?
if i could put things on different tabs but keep all the same flow.context stuff ive setup that would be great.. the main thing i need is visual organization.. ive been dreading the thought of moving nodes to other tabs because i thought id need to change all the flow context variables to global context in lots of function nodes ive made...
good to know using multiple nodes doesn't impact processing side too much.. i'll switch to dashboard 2.0.. i'll get it finished first and then treat that switch as another project in itself.. appreciate the help..
No, a subflow is different to a tab. A Tab is just a different page of the main flows (visual thing only).
No, flow context is per tab. This is a good reason to understand learn if you are using context unnecessarily. It is almost ALWAYS preferable to program "pure" (search pure programming principle) - it essentially means if you pass something into a function (flow/subflow) you should always get the same answer and should not have side-effects (i.e. not be reliant on things like global vars AKA context). For example, had you managed to avoid using context, you could very easily move your flows around. Now, you are learning why using context (or rather not using it wisely) is problematic - pretty much like how global variables (in any language) are discouraged (this is the same situation you have now)
You can however, add appropriate context values to the msg (using a change node e.g. msg.flowcontextStuff), pass that via link to another tab, use the msg.flowcontextStuff in the other tab, then when it returns, you can update flowcontextStuff if necessary.
And so you should - using flow context is bad enough, using global context has addition constraints (i.e. name clashes, even less portable).
I recommend you evaluate why you are using context. There may well be a good reason, and if so, there are ways to make it more portable.
without having heard the phrase before i think i intuitively understand the idea of pure programming.. seems like the more robust something is the less it would need to rely on external input.. for myself right now (with my level of skill) using flow context kinda helps to see the solution in my minds eye, i can see how it makes a design fragile though... i'll pay attention to trying to minimize it with the next thing i work on..
good thing for now ive got most of the functionality working in this little project and its been rewarding to build... i'll treat the task of tidying it up as a chance to improve..