Node-RED flow review process

General
1

I am currently working with Node-RED and ask myself how a professional review process for the flows can look like. The way I found with export the flow and add it to git isn't that nice from my point of view. At least if you have some custom JavaScript code.

Pain:

If a flow is exported this will be stored in a JSON file which contains escaped JavaScript code in one single line. I image there is some tool support (locally) to don't have it just in own file displayed. If I think in a production environment the process would look like the flow is exported and is committed to for e.g. GitHub. Now for the change we want to have a code review via Pull Requests. In this pull request the changes are really unreadable.

Example:

image
image3387Ă—635 115 KB

Do you have any experience on how to map this properly?

I am aware of the git integration feature of Node-RED but from my point of view there is the same pain of the review process.

2

Welcome to the forum @ChangeTheCode

By no means a complete solution, but I run this command to create a human readable version of the flow file as the file flows.json.formatted and commit that to github too. In settings.js, flowFilePretty must be set to true. Then the formatted file may be git diffed to see the changes.

#!/usr/bin/env sh

# generates formatted versions of node red flow files matching flow*.json
# in files flow*.json.formatted

# NOTE must have flowFilePretty: true in settings.js

for f in flow*.json; do
  echo $f
  sed -r 's/\\n/\n/g' "$f" > "$f.formatted"
done
# remove any cred files converted
rm *_cred.json.formatted
3

Yes that is great for expanding the json. I do wonder if that is really a great way to do a code review of a visual programming paradigm. I would have thought a walkthrough of the actual flow would be (or should be) a better way to try to understand what the flow is trying to do.

4

I use it just for reviewing differences within function nodes. It doesn't help with the flow level logic.

5

I guess in a professional production environment it is needed to have a review process. Currently I do not really see how should I review flow in the graphic surface. @dceejay it is a possibility to do this in pair to get directly an explanation from the author, that is fine. But can you then check if there is a change (diff) which could be relevant or create a risk / bug? From my point of view it isn't possible to see differences in the graphic surface and I am on the same side like @Colin to use this tooling to find differences.

@Colin thanks for this information I will try to enable the pretty formatting and check if this will help out more.

6

I agree - for diff then yes traditional diff/meld tools will highlight the differences more easily. As long as that is what you mean by review then fine. Normally I mean it to be your first example - of a walkthrough with the author - where I think visual flow would be better... - or indeed do both :slight_smile:

7

For reviewing the flow itself it might be worth looking at the techniques used for reviewing integrated circuit design, which is basically similar in concept. Functional blocks with inputs and outputs wired together.

Edit: or any other sort of digital circuit design for that matter.

1 Like
8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.