I am developing custom connectivity nodes (database, AMQP and etc.). I am still struggling to understand what should be the best approach to connections reuse.
All of the packages I looked into are using "config" nodes just for config store and every (UI) node instance maintains its own connection to the external system. This sounds strange to me, since Node-Red is running in a single process, and it should not be an issue to store the connection object in the config node and reuse this connection across other (UI) nodes. This approach should be a lot more resource savvy (i.e. DB connection is considered to be highly resource-intensive on DB server).
Your thoughts are highly welcomed.
It depends on the specific service, but I would say the expected design for something that maintains a long running connection would be to maintain a single connection in the config node and pool the connection between the flow nodes.
The core MQTT nodes do just that - the config node does the work to maintain the connection.
There may be some services where that doesn't make as much sense - where the interaction specifics make it harder to route a response back from that service to the right flow node that's sharing the connection. In those cases, each flow node needs to have its own connection. But I would consider that the exception rather than the rule.
This is exactly what I thought.
In this case, when the config node holds the connection object. The dependent nodes need to wait until a connection is established. What is the correct approach to implement this waiting mechanism?
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.