0
votes

Within Node-RED, we have the ability to create custom nodes. These perform specific work that is not supplied by the out-of-the-box pre-supplied nodes. There are many community provided instances of these. A custom node may wish to handle some new form of input event. Let us imagine that we have a new network technology called 2TinCans (2 tin cans connected by a piece of string). If we wish to handle a request/response using this, we might create two new Node-RED nodes ... one to handle input (the request) and one to handle the output (the response). When a request arrives, the 2TinCans server running in Node-RED is already listening for incoming requests. When the request is received, the node sends a new message down-stream. Eventually, this will reach a 2TinCans response node which is responsible for sending back the response to the corresponding original request.

Here is where the question comes in ... how do we maintain the "state" of this conversation such that the responding node knows to send the response to the correct partner?

1

1 Answers

1
votes

We need to maintain state and information originated at the original incoming request node that can be used by the final response node.

Within a Node-RED environment we have a number of context objects including a context per node, a context per flow and a global context. However, architecture does not allow these to be used for our purposes. The local node context is of no use to us since it would hold context for the incoming request node but that isn't addressable by the response node. Both the flow and global contexts are "singletons" ... that means that any data we save there is over-written by the next call. Since, in principle, there may be many concurrent flows being executed, we could imagine two parallel requests being processed at the same time and they would step on each other's responses.

The correct way to pass the correct state information to the downstream response node is to add that information into the message (msg) that is flowing down the wires. This could be in the form of a property that is a callback JavaScript object that the response node could invoke to complete the conversation.