Ok, this is a bit silly but I am sure people have seen this problem a few times.
A flow. Lots of nodes and outputs.
They are neat as they are, but you need to duplicate these wires (signals?) else where on the flow.
You have to add a heap of link nodes or run a lot of wires from where this set up is to else where on the flow.
wouldn't it be better if you could bus these signals together?
Two nodes: In and Out. (No prizes for guessing that)
The in node has multiple inputs, (User editable) and one output.
The out node is the reverse. (Maybe save the number of outputs.) One input and multiple outputs.
Then you connect up the signals to the inputs of the in node.
Connect that node's output to the out of the pair.
(Ok, you will need to edit the number of outputs)
Then connect the outputs to where they need to go.
Obviously #1 to #1, #2 to #2, #3 to #3 and so on.
I'm not of the ilk to be able to make anything like that.
(and there is a problem that there is only 1 input on a node.)
but you need to duplicate these wires (signals?) else where on the flow.
You have to add a heap of link nodes or run a lot of wires from where this set up is to else where on the flow.
Do you ?
Although I can see some benefit in your idea of a "bus", it will become convoluted very quickly and you still need to add lots of wires, lots of configuration and lots of figuring out where what you put on the bus and where it exists or not.
Link nodes already act like buses but "multiplexed" - you can use a switch node to filter if needed.
NR has all the flexibility one could wish for, but what is 'best practice' ?
The concept of a flow is from left to right, you have a canvas of 5000x5000 at your disposal.
There lies the problem. Node-RED enforces a single input and there is a good reason for that.
As soon as you try to allow multiple inputs, you hit the timing issue - Node.js is not realtime and you can never totally predict the order in which messages will arrive. So what should a node do that expects multiple inputs when it only has received some of those inputs? What happens if input #1 receives another msg before all of the other inputs have received one?
It gets very complex, very quickly.
With the link node, (or indeed any other) you can already have as many wires connected to an input. That leaves it up to you how to handle the issues.
And that is fine if each input is independent of the others - though frankly, in that case I have an out link for each flow and a single in link. That's how I handle most MQTT connections now, Telegram as well.
So I often have 2 MQTT out nodes defined for all flows, one has the retain flag set and one doesn't. Makes it fairly easy to see what messages are being retained.
With Telegram, you have an out node for each bot but may wish to send messages to it from anywhere.
uibuilder is similar. I took the decision to bundle everything into a single node because of the appearance of link nodes. Send from anywhere via a link out. Have a single link in.
A bigger issue arises if you need to coordinate messages and that was what I was really referring to as the reason NR doesn't allow multiple inputs.
Having a single link-in is a conceptual bus since all traffic goes through it. Of course, it doesn't have any of the other features that a true bus architecture would have like message queuing, back pressure, acknowledgements, etc.
But if you wanted that, Node-RED is the wrong tool anyway. MQTT will give you a subset of course. But an enterprise message hub will have a lot of additional features.
