How does Node-RED deploy work (codewise)?

[Mathieu Brouwers]

Hi guys,

I'm working on a opensource platform called Weaver.

With this platform we (or others) can create small webapps.

What we want is to be able to assign behaviour to viewcomponents, where the behaviour is written in Node-RED.

To get everything working the way we like to, we need to know the backend of Node-RED.

My collegue and I have looked into it, but we can't seem to figure out how the deployment (and running) of Node-RED flows work.

Could you help us out?

Greetings, 

Mathieu Brouwers

Sysunite

[Nicholas O'Leary]

Hi Mathieu,

it's quite a complicated thing to describe clearly as it really is the heart of node-red - as is an area of code that has been rewritten a few times to try to improve its structure and maintainability. So it depends on what bits in particular you're interested in.

Here's a high-level description of the entities involved...

A running configuration consists of a number of Flow objects - each one corresponds to a tab in the editor. There is also a global Flow object that owns the global configuration nodes and subflow definitions. The Flow object is defined in red/runtime/nodes/flows/Flow.js. The Flow object is responsible for creating, starting and stopping all of the nodes it contains. The basic Node object is defined in red/runtime/nodes/Node.js.

When a Flow object is created, it is given its own configuration as well as a reference to the global Flow object so it can access the things it contains. When the Flow is started (assuming a full deploy, not a modified-nodes/flows deploy), it instantiates all of the Node objects owned by the flow. If any of them are subflow instances, it creates a local instance of each of the nodes in the subflow. When a flow is stopped, it does the reverse; stopping each of the nodes it has created. In the modified-nodes/flows cases, the start/stop functions take a diff object that identifies what has changed as result of the deploy and what needs to be changed.

The creation/etc of the Flow objects is handled by the runtime in red/runtime/nodes/flows/index.js. It does the work to take the flow configuration provided over the admin api, convert the flat array of node objects into a structured object that can then be split up and passed to the individual Flow objects. (It also does the work to generate the diff of two configs in the case of a modified-nodes/flows deployment type).

I don't know how useful that is - whether you're looking for the high level conceptual description, or wanted a more line-by-line description. It would be helpful if you had some more specific questions.

Nick

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
For more options, visit https://groups.google.com/d/optout.

[Athiappan]

Hello Nick,

We are planning to embed Node-red with our web application. I want some more clarifications as,

1. What actually happens when we say "Deploy" in Node-red 

      - means in the background, how the workflow is validates

2. which execution engine is being used?

3. Is it possible to have "Single node execution" - to select any single node in a workflow and to independently execute that node alone in runtime?

4. Is it possible 

      - to pause any execution in the middle

      - to resume the workflow

      - to restart the workflow

Please elaborate and help me to get clarified.

-Athi

[Nick O'Leary]

Hi,

1. What actually happens when we say "Deploy" in Node-red 

      - means in the background, how the workflow is validates

When the deploy button is clicked, the editor creates the full JSON representation of your flow configuration. That is then passed over an HTTP Post request to the runtime. Assuming a 'full deploy' is being done, the runtime stops all current nodes and discards them. It then loops through each node in the JSON flow definition and creates a new node object of the appropriate type, passing in its configuration.

That's pretty much it. There are slight variations for 'modified nodes' and 'modified flows' type of deploys - the runtime determines what has changed and only stops/recreates the appropriate subset of nodes.

2. which execution engine is being used?

Node-RED's runtime is built on node.js.

3. Is it possible to have "Single node execution" - to select any single node in a workflow and to independently execute that node alone in runtime?

The runtime isn't really setup to do this - but it is something I'd like to explore more in the future when we think about alternative deployment models.

4. Is it possible 

      - to pause any execution in the middle

      - to resume the workflow

      - to restart the workflow

Not currently. Our roadmap (publised on the node-red blog a couple months ago) set out some of the things we're working on in the coming months. One of which is making the message routing between nodes a pluggable component. One of the reasons to do this is to create a flow debugger - something which will need to be able to pause/resume the flow engine. But we don't have that today.

To unsubscribe from this group and stop receiving emails from it, send an email to node-red+unsubscribe@googlegroups.com.

To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.

To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/59ba4ed8-8b46-453b-b6f1-5798366f128e%40googlegroups.com.

[Athiappan]

Hi,

Thanks a lot for your response Nick.

Just a workaround for "Single node execution".

Steps:

1. Drag and drop the needed nodes. Connect with wires. Do full configuration

2. Once we click on "Deploy"

        In the backend, the json will be created.

        < 

           2.1    we will create a backup for original json. 

           2.2    Then can we modify the json to have only the node to be executed(after validating the needed inputs)

           2.3    Give the modified json to nodejs to execute

           2.4     store the result of this single node execution separately ( temporarily )

           2.5     Then show the results to user. With his acceptance we can add to the preserved original json

         >

3. On clicking overall deploy, the preserved json(with modified results) is given to the nodejs to get executed

Need your valuable opinion on this. How much feasible is this? 

what all efforts will be involved?

Regards

Athiappan

[Kuo-Shou Tsai]

hi, Nick,

I am designing a as a workflow engine for executing a flow, which composed of some runnable tasks,  

I notice that the NodeRED runtime seems able to be the base of our workflow engine.

I want to know whether we can carefully customize runnable tasks to a (NodeRED) nodes, and wired  them as a flow, and execute the flow by NodeRED deploy? and the runnable task MAY mutate it mother flow instance by appending new runnable task at end of the flow.

is it possible to use NodeRED runtime for our specific (or somewhat strange) requirement?

thanks

Kuo-Shou

Nick O'Leary於 2017年9月26日星期二 UTC+8下午5時05分13秒寫道：