Flow Dev Guideline

This page is for discussing about how to make Flow Dev Guideline.

You can check the original contents at HERE.

• Making application with Node-RED
  • Components of Node-RED
• Style
  • Align nodes
  • Naming rule
  • Using proper nodes
  • Universal nodes that are not recommended for heavy use
  • Changing icon
• Designing a flow
  • Development process
  • Designing domain model
  • Designing flow structure
  • Designing messages
    • Parameter that stores data shared between nodes
    • Parameters that control the functionality of a unique node
    • In a node to which multiple messages with different types are input, add tag information for identification to each message.
    • Store a large amount of data in persistent storage outside Node-RED and reference the data.
    • Processing depending on the order of arrival of messages
• Implementing flow
  • Collaboration between flows
  • Implementing message
  • Managing environmental variables
  • Managing status
  • Flows that can have adverse effects
• Improving readability and reusability
  • Comment
  • Error Handling
  • Refactoring
• Development project
  • System and development environment
  • Managing flow
• Responding to strict non-functional requirements
  • Precautions due to single thread
  • Sequential duarantee
• Design pattern
  • Pattern regarding the structure between flows
    • Facade pattern
  • Pattern related to managing status

Making application with Node-RED

Components of Node-RED

Style

Align nodes

Naming rule

Using proper nodes

Universal nodes that are not recommended for heavy use

Changing icon

Designing a flow

Development process

Designing domain model

Designing flow structure

Designing messages

Messages can cause dependencies between multiple nodes. For other developers to reuse flows, it is important to design messages so that dependencies get to be relaxed. Therefore, this chapter proposes a guide about designing message.

Parameter that stores data shared between nodes

• Do not make multiple nodes use same property
• Importance of dividing data processed by node(msg.payload property) and controlling feature of node(msg.).
• How to prevent

Parameters that control the functionality of a unique node

• Recommended pattern of parameter setting

In a node to which multiple messages with different types are input, add tag information for identification to each message.

• Necessity of tag due to the fact that there is only one input port of node

Store a large amount of data in persistent storage outside Node-RED and reference the data.

• Points to note when handling large amounts of data

Processing depending on the order of arrival of messages

• The order of arrival of messages when processing multiple messages

// Accumulation of messages
var msgs = context.get('messages') || [];
msgs.push(msg);
if(msgs.length === ...) {
  ... // Process messages
}
context.set('messages', msgs);

Implementing flow

Collaboration between flows

Implementing message

Managing environmental variables

Managing status

Flows that can have adverse effects

Improving readability and reusability

Comment

Error Handling

Refactoring

Development project

System and development environment

Managing flow

Responding to strict non-functional requirements

Precautions due to single thread

Sequential guarantee

Design pattern

Well designed sample flows help development of flow, especially for Node-RED beginers. This chapter introduces general design patterns.

Pattern regarding the structure between flows

Facade pattern

Pattern related to managing status