Please do take a look. And note that breaking changes should slow down even further now that it has reached a more mature level.
Also, if I know how people are using it, I can adjust support accordingly. People rarely give feedback so I have to make assumptions.
And, as others have perhaps already touched on. 1-2 year lifecycles for node.js microservices is really quite a low change cycle. Node.js itself has a very aggressive lifecycle and if your industrial use falls very far behind, you are opening yourself and your customers up to a whole world of security and privacy issues.
This is something I come across in my day-job as I try to provide assurance and governance for health-related technology around the NHS. And it is something we are having to force vendors to deal with I'm afraid due to the ever growing risks.
I have dashboard made for myself from scratch. Running 3+ years and every break it had is made by me. Those happen only if I sometimes don't have time to prototype or test some addition and do rapid development directly on running instance.
It has seen all updates of underlying software jumps. Zero issues.
You may ask if it is even close to industrial requirements.... I don't have answers like this. But having deep knowledge about on what it stands gives the qualify I can promise out. Nothing more.
Dashboard solutions are not built for that kind of usage. The product can't be same time beginner friendly zero code and professional industrial.
Our core codes are all written in C, and they are consistent without any breaking changes in the past eight years,. Even though we have many feature and performance upgrades, sensors running firmware version 1.0 can still be used by the latest gateways and software.
Yes Node.js updates more frequently than industrial applications desired. Although we did not encounter any issues (we only use basic long-term stable functions), it is still a pain to go through lots of testing for each update.
It is also worth noting that FlowFuse, the primary authors/maintainers of Dashboard 2.0, built it for this reason.
We have many industrial customers running Node-RED in production/industrial environments, and the request for a modern/stable/secure Dashboard from those customers is a big driving force behind why it is exists in the first place.
We have made some of our customer stories available here if you are interested:
This is a typical balancing act between open source and commercial use. I think it is an unreasonable request as most developers here already take breaking changes into account.
There is a reason why companies pay other companies to use/deliver certain products: accountability and contractual agreements; I would resort to dedicated platforms which can communicate with node-red but are specialized and focussed on dashboards/control as their core business, something like peakboard.
Shifting towards the FlowFuse path seems the right way for commercial solutions. If you pay for something you also have the right to demand things, otherwise you can just hope & try to convince wih the right arguments. But you have no purchasing power
At some stage, since we started to talk aboout FlowFuse, it would be interesting to get a presentation of how much FlowFuse includes bits & pieces that comes from free time non-paid contributors. If any of course
Also if FlowFuse can be populated with typical Node-RED plugins? If so, no matter how well tested FlowFuse is in itself, adding nodes with various quality could change the equation dramatically
How I would love to have FlowFuse moved away from this board, it should be handled separately from Node-RED on it's own board. But then some parts seems so tighly linked together, like this Dashboard 2.0. Reason I wonder, "what else, what more"
Though I do have some sympathy since many industrial vendors have to operate on very tight margins.
However, this is not an excuse not to think carefully about how software and firmware is managed and monitored. There are many techniques to offset upgrade risks against testing and deployment overheads. And many fairly easy techniques for update distribution even across protected customer boundaries. Along with continuous integration and testing. Coupled with supply chain attack mitigation.
The supply-chain attack problem is something I've been thinking a lot about recently for work. Happily, this overflows into my work on UIBUILDER because it has made me much more conscious just how vulnerable Node.js-based products like Node-RED and UIBUILDER can be.
To that end, I've built a lot more supply-chain checks into UIBUILDER so that anyone wanting to use it can have much higher confidence that supply-chain issues (e.g. vulnerabilities or take-overs of downstream dependencies) are minimised. In addition, I've added code checks to prevent more direct code hijacks (and also my own occasionally stupid mistake) from becoming a disaster.
If I were a commercial organisation thinking about FlowFuse as a potential vendor, I'd be asking the same things as I've just outlined. What is being done to protect from supply-chain issues and how does the organisation monitor and protect its - and the JS-Foundation's code.
Paul, sorry if you feel that the suggestion is not constructive.
If an app/node does not have long-term support, stability, and changes frequently, then it is hard for industrial customers to use it. I do see the issues that exists, and this is the reason for this post.
Please ignore this suggestion if you feel that your software is not related to this.
Hi Joe, yes I am aware of FlwoFuse, and love the new dashboard 2. Most likely, we will adopt Dashbard 2 when it reaches stable stage. Personally, I think it is almost there.
If your suggestion is that breaking changes should be minimised then I think the point is that this is stating the obvious, and all here do already strive to achieve that.
