FlowHub.org - Gists for Node-RED

Share Your Projects
1

Hi There!

I've started a little project to itch a scratch that might also be useful for others. Ever since I've been using Node-RED, I've also wanted to share flows, either between projects or just to show others how Node-RED works. The solution has always been to send a long json string and ask people to import that string. (Between projects this is simply a matter of switching browser tabs & import/export.)

What I was missing was a preview and easy of use to share flows (i.e. flow tabs is meant in this context).

This began with the flowviewer to render flows in the browser without having Node-RED, then I wanted to compare different versions of flows but visually, this became the comparing tool. FlowHub is a combination of all that plus two extra nodes for pushing and pulling flows to/from FlowHub to/from Node-RED.

An example of what I have in mind is the web router flow explanation. The web router simply routes various http requests to the various handlers but no one understands what is going on by simply looking at the flow. What I wanted was to document the flow and allow others to use and improve it. It's just my way of doing request routing and I'm sure there are others.

So what's so new about the explanation? The flow is shown visually and can be zoomed/panned. Links in the text highlight parts of the flow and a mermaid flowchart tries to visually present the logic behind the router. Finally the various versions of the flow can be visually compared - not that much changed on that particular flow. (Also it's possible to view a particular version of a flow and then download that version.)

All the documentation (i.e. the explanation) is stored in the flow (the flow-tabs info box contains the documentation). So the flow is self-contained. My long term vision is to have an collaborative approach to development of flows that are generally useful and entertaining.

Of course, I might have created an NPM package with subflows but that is for me to static and not really simple. Also it means that I would have had to create all the npm collateral files (license, readme, package.json ....) for something that probably wasn't complete anyway. Plus I can't do that inside Node-RED - my aim is to extend Node-RED using Node-RED!

I know mermaid is coming to Node-RED 3.1.x, but I would - ironically - like to have documentation on flows that works outside of Node-RED. I.e. that works on mobiles and for newbies that might not have Node-RED installed. Besides the documentation for flows works inside Node-RED and at FlowHub - all mermaid diagrams are using "```mermaid" blocks.

Of course all this is a prototype and not designed for permanency rather as a test and tryout (i.e. things will break). It uses a public github repo for flow storage and a Node-RED instance as web server.

Cheers!

8 Likes
2

Just a short update, I've improved the UI to be more mobile friendly and added some more content. There is a complete list of flows is available as RSS feed. I've been adding flows that I have found interesting but also some learnings I've made:

But also stuff that surprised me:

All-in-all, Node-RED is a really nice tool for all sorts of things.

1 Like
3

@gregorius: is FlowHub in itself closed source or could I also spin up my own (private) instance somewhere? I really like your idea of sharing and documenting flows, but I don't want to share all of them publicly (especially in a professional context).

4

FlowHub the server is private. But for financial benefit to me, I can share the code with you!

After all I did spend a fair bit of my time working on it and my landlord does not get paid in flows - unfortunately..

2 Likes
5

Having said that, I am pleased that someone else see the potential in FlowHub.org - @striper I appreciate that!

Also if anyone is interested in financially or cooperatively helping in commercialising FlowHub.org into a SaaS product then please DM/PM me and lets talk!

1 Like
6

Thank you for the clarification. I was suspecting that, but I could not find the official statement :wink:
I fully understand and support your motivation. No doubt this costed you quite some effort to think up and build.
I will contact you via DM to explain my use case.

1 Like
7

This has always been a pet peeve of mine as well! I don't want to have to import a flow just to visualize the problem being described, or to understand how someone else solved an issue. Way too many discourse answers are simply "here is my solution... just import this flow".

In my opinion, the best use for this technique would be to automatically display in-line flows in both Discourse and the Flows library. Lately, I have been playing around with Mermaid myself. It looks like code blocks already support many different display formats (e.g. Markdown, Javascript, Json, Mermaid, PlantUML, etc) so it makes me wonder how feasible it is to extend support to the NodeRED flows syntax? Ideally it would be rendered as an SVG diagram with a "copy" button that puts the flow source onto the clipboard.

8

We added this to the Flow Library last September - Previewing flows on the Flow Library

1 Like
9

Excellent -- which shows how much time I've had to use the Flows library lately... :*(

So does this mean that the same rendering code could be added to the Discourse site?

10

It could. Writing a discourse plugin to actually do so is another matter entirely. I simply don't have the bandwidth.

11

I did create an oEmbed endpoint for flowhub.org so that I could integrate SVG versions of flows into LinkedIn posts ... doesn't work because they have an extra provider list :frowning:

Is there a way to whitelist FlowHub.org for embedding in discourse?

Something like this:

https://flowhub.org/o/embed?url=https%3A//flowhub.org/f/390ee0021ded4910

or this:

<iframe src="https://flowhub.org/s/390ee0021ded4910?oembed=1"></iframe>

Attempts when doing this:

Oembed:

https://flowhub.org/o/embed?url=https%3A//flowhub.org/f/390ee0021ded4910

Another attempt:

https://oembed.link/https://flowhub.org/f/7c29441a5cb63c9e

12

Sorry, my security antenna's twitched at this suggestion. I can't say that it sounds like a good approach.

Generally cross-domain data embeds need to be at least treated with great caution. What might happen if you made a mistake in the code or someone hacked your site? Could end up having a significant impact on Discourse.

I've not looked at Discourse add-ins and what they can/can't do but I think that needs to be the starting point, not hacking one site into another. Resource use on Discourse might also need to be taken into account as I know that we already push the limits.

13

I assume you don't use your CC to purchase stuff in the web? Or provide your mobile number to 2FA providers? Did you hear about the 26 Billion record leak? Perhaps your data is there already?

And installing random packages from NPMjs is also verboten? I personally don't like coding my own libraries, so I do install unknown, unchecked and unvetted third-party packages from NPMjs. But they are all safe because they come from npmjs.com ...

Thankfully I won't be at risk in coming to this forum now that we don't have any integration here.

So instead of having a visual representation of visual code, we'd rather have the textual, length json representation - since everyone here can visualise length Jsons in their heads, can reconstruct the original flow from that json representation and basically a textual representation of something inherently visual is far better anyway.

At the end of the day, IDC (I don't Care) - if folks are that worried about where they point their browser to, they should have plugins installed that block cross-site nastyness - uMatrix is not bad. But that is installed from a potential third party criminal gang - or what guarantee do I have when I install uMatrix from the Firefox app store?

But as long as I am safe here ...

Edit:

As clarification, what I should say is that if security argument stands in the way of making something simpler then we should avoid giving away our CC numbers, personal details and identities. We do all this because it makes life easier at the expense of our own personal security.

If third-party content is truly the problem, then uMatrix literally helps. When I open the above in my uMatrix Firefox I get:

Screen Shot 2024-01-30 at 12.19.38

I have to actively allow iframe-based third-party content. Anyone who is worried about this should be using uMatrix or something similar.

However not doing something - which might improve the current situation - because it could potentially be a security risk - in the future - then avoid using mobile phones and alike. Everything done today might be illegal tomorrow. This is obviously not an argument for doing nothing today.

14

That's why I don't use UIBUILDER since what if your site got hacked?

Edit / Clarification:

UIBUILDER is just as safe as any software retrieved from npmjs.com or any other registry of third-party software. I was not seriously suggesting that UIBUILDER is unsafe to use. Just as my site is as safe as most other sites include this one.

However is it legitimate to question the "safety" of a site as an argument to not to use the software that comes from that site? My reasons for not using UIBUILDER is not to do with the safety of @TotallyInformation website, it was an illustration of an argument that - for me - makes no sense.

Perhaps someone will hack @TotallyInformation account and upload a malware version of UIBUILDER to npmjs.com - I can't judge nor know, I trust that it won't happen. The same argument applies to software that is perhaps hosted on my site but yes, you'll have to trust me that it doesn't do anything bad.

To use that as an argument before anything has happened is the same as my original argument for not using UIBUILDER - and that was the illustration.

15

Just going to temporarily close this thread until @knolleary or @dceejay have had a chance to assess it

1 Like
17

Before I respond directly, I will reiterate something I published maybe a week or so ago. The repo for UIBUILDER has now had the recommended security actions applied. They are there to ensure that neither the UIBUILDER code itself nor any of its dependencies contain any security issues and to prevent unauthorised change. The UIBUILDER documentation also contains significant security information and guidelines for use. As someone professionally involved in cyber security and privacy for some nationally critical systems, I take this very seriously. Far more so, in fact, than most developers.

Which is, again, why I'd previously added the recommended protections based on stepsecurity.io

But, your use of software is a separate risk from service integration between two websites.

Take an extreme example. If my bank provides a web service and decides to use some specific 3rd-party code, it will assess the risks and add mitigations similar to the stepsecurity.io ones (except - hopefully - even more comprehensive) and it will have ongoing security testing to ensure security & privacy. They will also use change control processes to prevent unauthorised changes even from 3rd-party software.

But, if my bank decides to integrate a live service from some other source - lets say Coinbase - the live integration is a whole different set of risks because now, the bank no longer has direct control over what happens at the other end and cannot control what live changes might happen on the other end and so has no control over the risks that may evolve over time. This requires a different set of mitigations & controls. Typically by using either a messaging hub or an API interface to limit the integration impacts.

But back on-topic. I suspect that you may have thought I was suggesting that your website was somehow deficient in security - that was not my intent. The point I was trying to make was that ANY external website that integrates to the forum is a risk to the forum that the forum owners must assess. That could be from one of my sites or anyone else.

I think we are discussing at cross-purposes here. If someone choses to use some SOFTWARE on their website, that is one set of risks that they assess - and possibly add some measures such as the ones I've added to the UIBUILDER repo to help mitigate. If someone choses to integrate one website into another website, it is not just about the software in use. It is now an INTEGRATION issue. The risks are slightly different and need to be assessed accordingly.

In the case of this forum, it uses a public service as its host. Integration of another website might cause performance, denial-of-service or some other issues. Might is the key word here. There is a risk and that risk has to be taken into account by whoever runs the service.

But the key point is, that this kind of integration, unless done carefully, could introduce uncontrollable risks.

Security and privacy design MUST use risk-based arguments before anything happens. That is a fundamental requirement. For my house, I don't wait to see if anyone will burgle me before thinking about the risks associated with my doors and windows. I think about the local risks and issues, decide what risk I'm happy with vs the amount of money I want to spend mitigating them and then take action accordingly.

18

Please note, this topic was locked by a moderator to avoid it descending into an off-topic argument.

@TotallyInformation as a moderator, you are able to bypass that lock. However @gregorius is not.

Given you have posted to this locked thread, I will tentatively unlock it otherwise @gregorius will not be able to reply.

However please by mindful that I'm keeping an eye on this thread and if it goes off the rails, it will get locked again.

20

Fair enough. I won't, in any case be making any more comments on this thread.