Hi there,
I just wrote an article describing my experiences with NR and what I find good and what I find bad. It's kinda esoteric since I consider NR to be a complete development environment with more potential than just IoT and dashboards. I would like to bring this idea/notion to a broader audience and hence I wrote this article.
Medium link and archive.is link.
Corrections and Feedback and Comments most welcome!
Cheers!
Mostly fair I think. Couple of minor points perhaps:
You mention sub-flows several times but you don't point out that they create DUPLICATE code when deployed. This is a critical detail that sometimes catches people out. You also don't mention the alternative which is the use of the link-call node to access a section of flow elsewhere that can return - that does not duplicate code and so is a better choice in some cases.
Which also takes us onto point 17 about deep linking. Deep linking is certainly an anti-pattern in flow-based programming. It also isn't required because of the use of the link-call node. Visual programming should be visual and not have hidden paths.
The 2nd Con
No linting or other introspective tooling. The only checking of correctness is syntactical but on the other hand linting makes no sense in a visual flow based programming language. But other tools would make sense, for example path discovery between two points in the flow, i.e. how many flows send a specific email?.
Seems to ignore the existence of nrlint a linting tool for identifying potential problems with Node-RED flows
Thank you - Thank you also for the feedback. Part of writing the article was also to fill in my blanks.
I didn't know that sub-flows duplicate the code but that duplication is machine generated duplication, i.e. it's all in the server so the frontend user isn't aware of it. I would compare this with hash-defines in C whereby the compiler will expand them all out and the compile the resulting code. For the programmer this isn't a concern since it all happens in the compiler. I would take sub-flows, from what you describe, to be the same concept.
I explicitly left link-calls out since that would be getting to technical IMO. Good to know there are multiple approaches to avoiding code duplication.
The deep linking can be useful if you have complex flow and there is something amiss with a single node. I use it for highlight points in my mind maps, for example, https://demo.openmindmap.org/omm/#flow/a6381cd32644cdf0/n/c6e2de8178aac0b1
Id after the /n/ is the node id. If click on the link, it will show the flow and highlight the node in question. So it has nothing to do with execution of the flow and is purely a frontend feature for sharing specifics with other people. Since it contains the node-id, these links are not intended to be long lived since nodes can disappear, so this would be something for a slack chat or messaging someone.
I hope that clarifies what I meant by deep linking in this case, the term deep linking comes from a previous life of my and means something completely different in the world outside NR - I understand the confusion 
Cool, Thank you for that! I did indeed miss that, I'll add to the article as a correction. 
RE Con 4:
There is no clear way to support a testing-staging-production deployment/development strategy.
This is true and will probably remain that way (IMO). However there are efforts outside of and around node-red to improve this. For example this is being tackled right now in FlowForge - scheduled for the next release (disclaimer, I work for FlowForge)
RE Con 13:
You can have strange bugs if the
queryattribute is defined onmsgsince the Postgres node will always take thequeryattribute before the query defined in the node itself
I am certain you realise the Node-RED team cannot enforce 3rd party node developers to follow design patterns - in particular, I always try to follow the (unwritten?) rule of "leave a field blank to use msg parameter". And with newer nodes, I personally recommend the use of the typedInput so that user can clearly see where the data comes from / goes to, without any surprises in the msg object.
RE Con 17:
Deep linking to specific nodes is not supported
It is in 3.1.0 (currently in beta)
You can even link deeper into the edit dialog
Oh my! I didn't know that!!
I don't remember seeing that in the release dialogue?
yeah, it may have been in 3.0.2 (I forget)
Useful for teams when you send em a link and say "take a look at this" and for automated emails "generated >here<" with a link to the node/group/tab
@Steve-Mcl Thank you for the feedback, much appreciated
That is of course for me not to know. It remains a con for NR since NR does not support testing/staging etc. Sure I could take ten other products and build a pipeline around it but that's not "NR supporting testing".
If I can ask, where exactly does the development of NR end and the development of FlowForge begin? Since the core teams of NR and FlowForge do have overlap, I was wondering whether there are going to be conflict of interests between the two products, with some features only available behind a paywall using FlowForge. Disclaimer: I'm not criticising anyone for trying to make money of their work, simply asking about conflicts of interests, developer time and feature priorities!
I'm definitely not expecting anyone to change anything, basically the 'con' isn't a con, it's gotcha - mea culpa. Had I spent more time thinking about the structure of the article, it would have been pros, cons, and gotchas - several of the cons are gotchas and not cons. This being one of them.
On the other hand though, a simple us v. them type of article gets more attention than a "here's what you gotta watchout for"-type of article - controversy sells.
Which remains me, I'd better add the fact that I wrote the article based on NR 3.0.2! Good to know that it's coming.
Which also reminds of the nrlint comment above. Why is that not available in NR out-of-box, perhaps something that can be activated in the settings. It would draw more attention from end-users to the discipline required to keep flows understandable.
Same can be said about some of the commonly used extra nodes - "why not bundle them all ?"...
Node-RED was always designed (or at least envisaged) to be extendable via plugins and add on modules / nodes. This is one of those. The advantages of it not being included in core are
a) it doesn't add "bloat" for those users who don't need it eg machines in production
b) doesn't add another set of dependancies that need to be maintained
c) and which may contain vulnerabilities that trigger scan alerts that do not impinge on operational use....
d) doesn't tie it into the core release schedule - ie it can be updated on it's own timescale as people add more / better tests.
e) is easier for people who do want to enhance tests to get their head around just that bit of code rather than the complete codebase.
Completely agree with those ideals and more project should keep those ideals in mind - IHMO. I guess from my perspective - thinking of NR as a complete development process/tool - it would make sense to have a linter available hence my question. Everyone has their visions for NR and so it becomes, over time, harder to maintain those ideals and not to make exceptions.
This next wave of questioning those ideals will be AI and why doesn't NR have a "AI create me a flow for peeling bananas and it can't have more than 5 nodes"-feature built in. Its a pity that tools such NR will be less relevant since the belief will become that AI will solve all programming problems in no-time for no-money. Enough said, I will go back to eating my banana now.
I think you will find that assumption to be rather premature. The so-called "AI" tools "simply" rehash what already exists. Their ability to actually create something fundamentally new is little to none. So we will still need programming and prototyping tools. What may change is that the ability to take a logic prototyped in Node-RED and use AI to convert to another language might become feasible.
I am definitely not the person to be saying: a day without using AI is a bad day, much the opposite. I find that we as humans have to accept that AI is, as you imply, a predictive engine that simply has far more data than any single one us can keep in their heads and on the basis of that data, can make predictions that we consider creative or insightful. Much as an encyclopaedia has far more knowledge than any of us, AI is as if we open the encyclopaedia at a random page and are amazed by the contents and believe the encyclopaedia made that happen, i.e. the encyclopaedia is intelligent.
But the world is a financial, money-oriented world whereby anything that is cheap and seems good is great. Companies want to make more money - per definition, companies are there to make a profit and not to make the world a better place*. We as humans associate more money with better world but thats a false assumption. Hence my comment on AI - companies will replace people with AI as long as we humans can't tell the difference between the two. AI will always be cheaper.
Ephemeralization - Wikipedia -
to do "more and more with less and less until eventually you can do everything with nothing,"
That for me sums up the world that we are living in. On the basis of that, one can draw ones own conclusions about the future.
*=Of course what does "better place" even mean? Better place for AIs, Better place for the poor, Better place for the rich, Better place for us humans in general? My argument falls apart if one believes in evolution and will realise that better place for the planet might be a planet without destructive, wasteful creations.
AI will continue to be a SISO system for a while yet. So as long as you all keep posting perfect working flows then it’ll learn just fine
Took me a moment 
I used to use that phrase a lot. Never seen or used it abbreviated tho.
But 
agree Dave.
There seems to be a few definitions 
| Acronym | Definition |
|---|---|
| SISO | Single Input, Single Output |
| SISO | Serial in Serial Out |
| SISO | Shift in Shift Out |
| SISO | Simulation Interoperability Standards Organization |
| SISO | Soft-Input, Soft-Output |
| SISO | Society of Independent Show Organizers (US) |
| SISO | Senior Information Security Officer (various organizations) |
| SISO | Serial In, Serial Out |
| SISO | Senior Intelligence Staff Officer (Australia) |
| SISO | Second In, Second Out (accounting) |
| SISO | Spiral-in-Spiral-out (resonator) |
| SISO | Seguridad Industrial y Seguridad Operativa (Spanish: Industrial Safety and Operational Safety; Guatemala) |
The third is closest...
Is that FIFO, LIFO, or FILO?
(Knew I shouldn't have had that pint of local ale at lunchtime!)
That's exactly why all the flows I post contain a subtle error (or several) 
Now I'm confused, I've obviously misused the term all these years - sunshine in, sunshine out I thought. Hm...
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy