Interesting! I am still attuning myself to both products, but I would see the value. FlowFuse already offers performance metrics insights per instance through their product, but is not a straight up terminal. This is mainly ot understand performance I would assume? What usecases do you use the terminal for?
Can you elaborate here a bit. What UI do you often hide or not need (I assume)?
I assume this is for the same usecase as needing a terminal directly, correct? Also, are you thinking here in just your local network or some kind of secured connection with instances outside of your LAN (with e.a. wireguard etc)?
Afaik, this is kind of what FlowFuse does already by allowing you to easily manage multiple/many instances from one (shared) interface.
When I hear the word terminal, I always point at xterm plugin for NR. might or might not be appropriate in this case.
2 Likes
Although I completed the survey at the start of the week, I wanted to highlight one feature that would be extremely helpful during wiring: pan and zoom support. I regularly use EasyEDA for PCB routing, where the mouse scroll wheel controls zooming, and the right mouse button enables panning. This makes it easy to start routing a wire, then zoom or pan to the destination point without interrupting the process as the wire remains attached to the cursor throughout. The same intuitive behavior applies to moving objects or groups, and greatly improves workflow efficiency. If something like this was available in Node-RED - then that would be brilliant.
6 Likes
Panning is already supported, clicking down the middle-mouse button will pan. Zoom is options+scroll on Mac (not sure of Windows equivalent), but the scroll is done from the middle of the canvas, rather than where my mouse is, which isnât desirable.
3 Likes
In that case, can we please have the cursor change when panning. 
Also, how to those poor folk who are forced to use Apple Macâs cope as they only have 1 button! 
+1 for that. But I wouldnât vote for it to be built in. Also where is the terminal to be running? On the client device where the browser is , or on the server. Not quite the same ask as for vscode which is only running on one device.
3 Likes
I absolutely agree with that as I think I intimated further up the thread. Not everything needs to be crammed into Node-RED. Our Node-RED âhammerâ does not need a chainsaw attached to it.
Amen to that. Or as they say today: true that. Or 100% this.
Total agree. Please don't cram this stuff into Node-RED.
Less is more when it comes to Node-RED.
Open up the internal APIs so that node packages can do more, things like being able to gets a heads when Node-RED starts/stops/restarts/flows reload, clearly defining when the lifecycle of a plugin begins, accessing the events when messages get passed around.
3 Likes
On the server. Exec nodes run on the server, so the terminal would also be connected to the server that served the editor.
A more general solution would be able to store ssh keys in Node-RED and then select the ones to which one wants to login to. Something like visualising .ssh/known_hosts and then being able to login to any machine.
One step further: have a tmux-like experience whereby one connects to multiple machines and executes the same command on all of them at the same time.
Especially if windows where detachable in Node-RED, this would be a fun experience!
I believe that would be a very bad route to take. security keys should be kept in their native or other secure stores, Node-RED cannot be that.
Even having known_hosts in Node-RED may be an issue - I havenât really thought it through. Certainly it would need some careful thought before committing.
It is generally not good cyber security practice to combine security data with other systems as it gives more vectors for attack and failure and makes systems more brittle.
Personally, I would be against building such a thing into Node-RED itself. Too much complexity, too many ways for it to be attacked or otherwise go wrong.
A contrib node perhaps though I personally would certainly be very wary of using such a thing without seeing some serious security testing.
Well, each to their own! 
I am more than happy having my remote terminals separate and dedicated. Even with remote VS Code, I rarely use the terminal except for a quick npm update or similar, I have Windows Terminal which gives me a far better experience in a tabbed interface where I can tear off a tab if I need to.
I want the user flow to be exactly as the one I do when writing code in vscode, but for when writing flows with nodes in node-red. The keys to my remote node-red instances would be in my host machine at .ssh, and somewhere in a node-red client running locally, which also has access to .ssh, there would exist a âconnect toâ button that would list the remote hosts based on the list of hosts from .ssh/config. Once I select one of the hosts, a new browser tab running would open but this one would be connected to the host I selected. I want the same experience as found in vscode.
Quality of Life improvements regarding the editor and management is high on the list for sure! Keep the little details coming. Taking them all along!
PS: Survey activity has been quite good so far!
FYI: the survey will run until Aug 16th!
If you know anyone who would be a valuable respondent, please share the url with them :).
1 Like
I've asked a question on the new UK Government Low-Code digital community to see if anyone else in government is using it. If they are, I will send them the link if they don't already have it.
4 Likes
Does it really exist? Is it a reddit community?
Yes, it really exists. No, not Reddit, nor even Slack. But rather Teams.
Sadly, mostly occupied by MS Power Platform rather than a real low-code tool like Node-RED! 
Iâve done the survey, but I forgot two functionalities, that would be great to have:
- Node-RED has awesome data transformation possibilities with JSONata (itâs a beast, but powerful). What I miss is data validation functionality to check, whether incoming data is appropriate. Something like Zod, but in a way that feels more ânaturalâ for Node-RED.
- Mustache templating is fine, but it is very restrictive. Would be great to have more flexible templating language in the core. One could argue, that data preperation should be done before templating (with JSONata, for instance), so Mustache is sufficient (or intended), but I think preparing data for display purposes is better placed in a templating language (date and number formatting and so on, calling functions from templates somehow - maybe).
1 Like
There is json schema validation which partly perhaps provides what you're looking for. Admittedly JSON Schema is a horribly complex and is a real pain to get right.
Mustache is designed to be functional limited because the intention is to have no logic in your templates. Which is a good thing. IMO everything else is a road to nowhere - Talking Heads.
