Skip to content
This repository was archived by the owner on Dec 16, 2020. It is now read-only.

Limitations

Jump to bottom
Nam Giang edited this page Aug 7, 2018 · 1 revision

DNR, like Node-RED, is a data flow-based programming model

Thus, it has its own limitations and is not applicable for all class of applications out there. Here are some problems that it does not fully support at the moment:

  • Support non-serializable objects: since DNR has to send the message to an external devices, it has to serialize the object before sending out. This is not always possible for all existing Node RED nodes as many of them use non-serializable object and passing the pointer between nodes. For a local, single device deployment this is ok as the object can be retrieved using its pointer. But not if it has to be sent to an external devices.

  • Support stateful nodes: some Node RED nodes are stateful, they keep their state within the system and the nodes share the state by keeping a pointers to it. In a DNR setting, when a message is sent to an external device, the state of the sending node is not sent along with it. When the message arrived back to the device, it does not know the existing state of the system.

Http nodes are a typical example of these requirements. 1) http nodes keep a circular object with their message (req, res objects) so that it can be used by other local http nodes. 2) http nodes keep the state about the current connecting sockets so that they can send the response back to the right clients.

DNR is a distributed programming model

There are a class of nodes that D-NR studio does not fully support, because they were not designed for distributed systems. They are the nodes that have a strong coupling between the node's frontend and backend (strong coupling is bad for distributed systems right?).

That is, their rendering of the node's frontend requires their backend to run. In case you're wondering, Node RED nodes implementation consist of a frontend and backend part. The frontend is loaded to the editor browser and the backend is executed in the runtime. Usually the frontend serves as a visual programming tool that dictates how the backend run.

The Dashboard node set is one example of this class of node. In its unusual implementation, the node's frontend, which includes a tab to configure the Dashboard (the Dashboard tab) requires the node's backend to run in order to render correctly.

On DNR, all nodes' backend are disabled internally by design because we only work on the design canvas with node's frontends, the real executions of nodes are handled by participating NR. Thus, the nodes' frontend won't be rendered correctly (e.g the Dashboard tab will appear empty in DNR)

Clone this wiki locally