-
Notifications
You must be signed in to change notification settings - Fork 154
Node Dev Guideline
This page is for discussing about how to make Node Dev Guideline.
You can check the original contents of Creating node definitions for Node-RED (node generator) at HERE.
- Introduction
- Purpose of node development and correspondence of this guideline
- Terms
- Designing
- Policy for designing original nodes
- Coding
- Official documentation of Node-RED
- Procedure of development
- Describing code
- Style
- Official documentation of Node-RED
- Naming rule
- Design
- Improving quality
- Test
- How to run the test
- Static analysis
- Manual test with operatig Node-RED
- Automated test with test code
- Original test items of node development
- Security and anonymity
- How to write credential information
- How to code obfuscation
- Appendix
- Tips and Notes
- Creating node definitions for Node-RED (node generator)
There is possiblity that standard nodes of Node-RED can not deal with every use case. Node-RED allows users to develop their own original nodes. This guideline explains guideline and precautions for developing nodes.
| Terms | Meaning |
|---|---|
| Original node | Original node A node that performs generally useful process logic. |
| ELN (External Link Node) | A node for operating EFE on Node-RED. |
| EFE (External Flow Engine) | A system that prepared interface for receive the process order from Node-RED. |
| Original system | A system that used by users on Node-RED independently. |
This chapter explain the policy of designing nodes for developers who make original node.
Firstly, there are documents about how to create a new node in the Node-RED official site. Therefore, the page should be given preference.
- Designing interface
- Writing code
- Test
- Multilingualization
- Packaging
Creating a simple node or template of node could be easy for using node-generator.
The looks of nodes such as node's name, color, and icon affect the readability of the flow. This chapter give some tips to developers when they create multiple nodes.
The appearance of the node is explained in Node appearance. But, I think that it is neccessary to add the contents about rule of naming node because it is not on the official website.
When categories name and node name is similar to ones made by other developers, it is difficult for other users to distinguish them. If the category name or node name of your node is exactly the same as that of other developers, one of them will not be displayed on the palette. Therefore, these names need to be sufficiently unique.
Also, too long names reduce visibility.
This section describes guidelines for naming conventions for these problems.
It is important to ensure the quality of it, because node could be used in every flow, and the quality of the node influences the quality of the flow. Therefore, this chapter explain about tests as quality improvement.
If the developer includes the credential information in the flow data as the property value of the node, the credential information is shared with other people when sharing the flow. And it could cause an unintended operation. Also, when place the developed node in the repository, the contents of the source code could ve read by others. This chapter describes about handling of credential information and a method of code obfuscation to prevent these bad events.
- Make state of the node can be grasped from the workspace
- Do not implement a server feature(Web server, etc.)
- If you need establishing a session with another server, do not discard the message arrived before establishing it
- Do not embed personal information
- Group the related function group of the original node into one node
- Do not assume the execution order of nodes
- Do not perform sequential processing for a long time in the node