Add design note for standalone Node-RED

[kazuhitoyokoi]

I added design node about standalone Node-RED (Electron version of Node-RED).

[dceejay]

Should it even use the ~/.node-red directory if it is self contained ? If someone already has Node-RED installed should this interact with it or not ?

[kazuhitoyokoi]

As you wrote, I think that there is no need to interact with the normal Node-RED environment. I changed it to ~/.node-red-standalone directory for the standalone environment. Let me know if there is another appropriate name for the directory.

[dceejay]

so would this also install git ? Or is git a prereq ? Or should it autodetect and not enable projects etc.

[kazuhitoyokoi]

If installer support to install git command, we need to add different handlings for Windows, macOS, Linux environments. Therefore, I think that prereq and auto-detection are suitable for the project feature on the standalone Node-RED.

[dceejay]

Should it always try to run a flow ? last opened flow ? Or should it always start in "safe mode" - as this is now more of an IDE model.

[kazuhitoyokoi]

Absolutely. "safe mode" is natural in an IDE model. I added the text about it.

[knolleary]

I'm not sure I agree. It really depends how far down the IDE model you want to go.

A full IDE like model would let you open up multiple different flow files, save them separately, run more than one... is that the type of model we want? Until we've set out the basic scope of the IDE, then we simply cannot start discussing individual details about the implementation.

[kazuhitoyokoi]

@knolleary Thank you for your comments. I added the scope of the standalone Node-RED. Could you review it?

[dceejay]

why not use system log files so linux can autoclean them up ?

[kazuhitoyokoi]

The auto clean by OS will be useful. I changed the file path to /var/log/node-red.log. winston-syslog module seems to be able to store the log data to this directory.

[dceejay]

electron-builder can build deb and rpm

[kazuhitoyokoi]

Yes, electron-builder can build various types of binaries. To reduce our tasks to check all binaries in every release, I wrote three major binaries. I would like to suggest documentation about how to build other binaries like deb and rpm.

[knolleary]

I've been doing some thinking about some of the basic design decisions to be made around Standalone Node-RED. The goal here is to provide a good user experience that is more than simply putting Node-RED in a native desktop window. I've also identified some technical issues with Electron that need to be addressed from the start.

1. Using Worker threads to run Node-RED within Electron

We know that node.js is single threaded. When running Node-RED today, you have the runtime using the node.js process and the editor is running in its own browser process. They are separate processes with no connection other than the editor's http calls to the runtime.

Inside Electron, you have the Main thread and the Renderer thread used to update the BrowserWindow. Whilst they are separate threads, I have read a number of posts that warn against putting heavy workloads on the Main thread as it can block the IPC between the Main thread and Renderer and impact the UI performance. (reference)

The recommended approach is to put the heavy workloads in Worker thread.

This opens up another interesting possibility...

2. Run multiple Node-RED instances

This isn't a Version One feature, but I think it's something to have in the design in order to make some right choices at the start.

I can picture the Node-RED IDE providing a UI similar to Slack, where you can have multiple Node-RED instances in the application. Each instance would be a fully self-contained Node-RED instance, with its own userDir and a unique port number. This will make it easy for the user to spin up multiple, separate instances of Node-RED.

It should also be possible to add a remote instance that is already running elsewhere. For example, a user installs Node-RED on a Pi using our script. They then open up Node-RED IDE on their desktop and "add" the raspberry pi instance to the workspace.

3. Installing new nodes

I don't think I've seen this discussed: how can the user install new nodes? Electron doesn't include npm (as far as I can see) - so would need to include it ourselves. How would we do that?

We then have the issue of installing modules with native modules. This page in the docs explains what is required to do that - https://www.electronjs.org/docs/tutorial/using-native-node-modules.

4. First run experience

The first time the user runs the Node-RED Desktop app, we should prompt the user for any first-run configuration that is needed.
If we go down the route of the supporting multiple instances, it could prompt the user to either create their first Node-RED instance, or to connect to an existing one.

If they create their first instance, we can ask a number of questions to preconfigure it. For example, configuring user security to encourage a secure-by-default approach. I'm sure there will be other config options we could consider here.

5. Editing the settings file

Following on from the previous suggestion, the user ought to be able to customise the runtime further via the Desktop app. I don't mean by editing the settings.js file, but via proper a proper UI experience.

[dceejay]

Yes - 4 and 5 were what I was getting at with the Refocus Issue - I think a good consistent install / customisation experience would help avoid a lot initial issues.

1 & 2 - Interesting thought - and yes a cleaner separation would make sense. I suppose first up it could make the main app more of a "project manager" and just switch between (non-running) projects - or does that head too much towards being a VScode plugin ?

3 is potentially v. hard - there seem to be lots of issues around various packages (mainly with native code not cross compiling) or otherwise being incorrect engine versions that stop things working.

[knolleary]

If we can't solve 3 then we shouldn't do this work - or at least, we shouldn't use Electron. There is little benefit making it easier to install Node-RED if you can't also install nodes.

[kazuhitoyokoi]

Thank you for the discussion.

3. Because the npm is provided as an npm module, we can add it to dependencies in package.json of node-red-desktop (node-red-installer). To support it, Node-RED core needs some modifications to call npm module. And we need to consider handling when updating the Node.js version in electron. I think that the node-red-installer needs to have npm rebuild handling for installed nodes under the .node-red directory.