-
Notifications
You must be signed in to change notification settings - Fork 151
Flow Dev Guideline
This page is for discussing about how to make Flow Dev Guideline.
You can check the original contents of Designing messages and Design pattern 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
- Implementation of flow
- Collaboration between flows
- Implementation of 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
As the size of the application increases, the processing contents become complicated. It makes it hard to understand by other developers. Therefore, it is important to make the process easy to understand with better node alignment.
Name to nodes and tbas also affect readability and reusability of flows. This chapter present some examples useful for it.
If nodes are used for different purpose, there is a possibility of erroneously recognizing the flow. This chapter introduce how to representative nodes such as Change, Switch, Template, Link, HTTP for using these as the original role.
Function node and Exec node may be easy to use for skilled developers because they can write down JavaScript or command directly. However, heavy using of these make contents of the flow hard to understand unless some one check the each node. This chapter is a caution to prevent about it.
When the same kind nodes are in the flow, it is difficult to distinguish nodes. But, it can be solved by designating different icons for each node. This chapter introduce the procedure for changing the icon and some Use Cases.
When develop a flow has complicated logic, it is better to design and develop strategically.
As the volume of the tab increases, the division of processing becomes ambiguous. If the flow is intended to be reused, it is necessary to decide processing contents and scale of one tab before implementation. For that reason, it is better to organize what kind of things, people, work, rules are in the target domain of the application, and what relation it has.
After designing the domain model, consider the structure of the flow that reflects it.
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.
- 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
- 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
- Points to note when handling large amounts of data
- 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);One service may be constructed by cooperation of a plurality of services. Therefore, in order to make the flow easier to use from other flows, it is better to make it possible to start by receiving the process with an HTTP request. And response is returned to the flow of the request source when the processing of the flow is completed.
In message processing, messages to be sent can be newly generated, but there is a possibility that problems may occur due to the loss of properties contained in the input messages. Properties in the input message should also be kept in the output message.
If you use the global context from various flows, it becomes difficult to identify the dependency part on the global context, and bugs tend to occur. Therefore, it is necessary to make it easier to see the portion where the operation of the global context is performed from the flow, and to minimize the dependence on the global context.
It is necessary to manage the execution status of the program in the recovery process when an error occur such as calculation processing targeting multiple messages, sharing information among multiple nodes, process depending on Node-RED External status, recovery processing at error occurrence.This section describes the policy of state management in such processing.
- Type of status
- Maintaining flow status
- Maintaining node status
Node-RED has high computability and can describe diverse processes concisely. However, due to its flexibility, it is also possible to describe a flow that can deplete execution engine resources, such as a flow that falls into an infinite loop, or a flow that does not end error processing forever, which can adversely affect the entire system. This chapter establishes certain principles in flow design.
- Designing Loop
- Comment on tab
- Comment on flow (Comment node)
- Comment on subflow
- Logging strategy
Error handling is needed to handle errors in order to improve reliability. In Node-RED, error handling can be expressed in flow as with normal system. This chapter explains its implementation method and flow arrangement.
It is better to check the developed flow before presenting it to other developers or before making it into a template.
- Coding Style
- Flow implementation
- Readability and reusability
In general system development, it is common to develop with established rules about such as unification of terms, code structure, development environment and procedure to improve development efficiency. This chapter explain the project management when developing flows with multiple people.
Well designed sample flows help development of flow, especially for Node-RED beginers. This chapter introduces general design patterns.