![]() (NOTE: Decreasing the chunkSize might increase the CPU usage) Development Try it on Gitpod If you decrease these parameters the upload speed will decrease. If you increase the simultaneousUploads and chunkSize the upload speed will increase. More configuration options can be found in the Flow.js documentation. SimultaneousUploads Number of simultaneous uploads (Default: 4) The last uploaded chunk will be at least this size and up to two the size, see Issue #51 for details and reasons. ![]() If a function, it will be passed a FlowFile. Whilst the default labels may be sufficient in the context of the flow itself, it is also possible to customise labels to provide more detailed information.The config parameters you want to set are:ĬhunkSize The size in bytes of each uploaded chunk of data. They can help quickly identify the purpose of each branch in the flow. This is where adding port labels can help document the intended logic.įor example, the Switch node provides default labels for its outputs that are shown when the mouse hovers over them. If a node has multiple outputs it can be hard to follow the logic if it is not clear on what condition a message may be sent from a particular output. The names should clearly identify the start and end point of each flow. If you consider the Link nodes as providing APIs between the different tabs, then a good choice of naming scheme will be needed. That makes it hard to identify the right target node and mistakes can happen. Without a name set, you have to use the Link node’s internal ID when creating links between different tabs. It is also very important for Link nodes. This should be used with care as the icon is one of the main ways of identifying the type of a particular nodeĬhoosing good names for things applies just as much to the tabs and subflows used. For example, if you have a number of MQTT In nodes for different types of device, customising the icon to match the type of device could be helpful. The shorter the label, the less information it can share.įor some nodes, it might be appropriate to hide the label altogether to minimise the horizontal space it uses in the flow - giving more room to other nodes.Īlong with the label, nodes can also have a custom icon. ![]() The longer the label, the more space it needs in the flow. There is a balance to be considered here. A name of Get current time would be much clearer. That helps somewhat, but it doesn’t reveal the full purpose of the node. This should be used to properly label the key points of a flow.įor example, if a Change node has a single rule that sets msg.payload to the current time, its default label will be set msg.payload. Most nodes have a name property that can be used to customise the label they display in the workspace. That is particular true if that smaller section could be reused elsewhere in the flows. In some cases, these smaller sections may be candidates for moving to subflows that will reduce the visual complexity of the flow. Vertically aligning logical segments of a long flow The editor’s default behaviour of snapping nodes to a grid on the tab helps keep them aligned. The approach that gives the greatest legibility is to keep each unit of processing on a single horizontal line wherever possible. The goal is to make it easy to follow the flow without having to jump around the workspace or have to follow multiple wires that cross each other and appear tangled. This section considers the visual appearance of the flow layout. The flow structure section of this guide looked at how to arrange the logical components of your flows. More complete documentation can be added at the node, group or tab level.Moving commonly used parts into subflows can help reduce the visual complexity of the flow.Groups can be used to identify discrete sections of the flows.You should make sure the purpose of each node is easily identified and that they are well laid out to minimise how much wires cross each other. The flows can be read in the workspace to see the logical flow of events.In a visual programming environment like Node-RED, the documentation can take a number of forms. When you write documentation, the act of writing out the behaviour could well help you identify parts that could be improved.If a flow provides an external API you will want to document how that API should be used - what properties or parameters are expected.If you are sharing a flow with others, it will help them understand what it is doing and how it works.Whilst everything may seem obvious as you are building a flow, your future self will thank you for providing some description of the details when you come back to it later.Good documentation serves a number of purposes: In any programming language, a vital part of creating easy-to-maintain code is to ensure it is also well documented.
0 Comments
Leave a Reply. |