If you put it all in a github repository then others could pick it up from there, but also it would give you version control and backup for yourself.
2 Likes
Humph! 
You've been able to do that with UIBUILDER for around a DECADE now!!!! 
Or with REACT, or any other front-end framework. Or with no framework at all since most data-driven web apps that people are building with Node-RED really don't need one, HTML/CSS/JS is more than powerful enough on its own.
1 Like
Reminds me of one of the very first PC projects I ever did professionally - a warehouse management system for Cadbury's and their brand new (largest in Europe at the time) warehouse. Written using DBase3+. That was back in the mid 1980's. 
Written using a "luggable" Compaq "Portable" PC with a 12" green screen and a 5 1/4" floppy drive! 
1 Like
spot on @Colin 
I'm in the same 'Don't do what you did' camp.
I made Node-RED public facing. Big mistake it would seem.... After a very (very!) rocky few years and a somewhat insane learning curve about what not to do, its actually settled down and is supporting 2000 users per day most days.
Nice to know there are two of us.
Here is my main 'dont do that' post: Dashboard load times > 30 sec with more than 250 connections to website
And some of my weird learning curve is here: Dashboard metrics widget (connected users / load times / memory use) Ā· Issue #403 Ā· FlowFuse/node-red-dashboard Ā· GitHub
@Tim99 Thanks for the share and good to see that its working for you.
Where I struggle with dash 2.0 is responsive. ie, both mobile and desktop.
If I could chose just one and only one, then perhaps. Mabey.
The other issue is data tables. Having a LOT of data tables is just an ugly mess with responsive in the mix. Your app seems to be clean due to being simple. Most of my tables are ~10 columns and 50+ rows.
2 Likes
Two and counting! There are many more unfortunately they are users that are similar to dark matter: one can't measure them but the theories prove they exist!
From reading this and your reply, it seems there are - at least - five separate approaches here:
- putting the dashboard online using a skin - what you have done
- using the dashboard 2 template node to create a mobile app - what @Tim99 has done
- using Node-RED as an API backend for some other frontend technology (i.e. python) - that's the RedBack I was talking about above
- using http-in and templates nodes to create a website using Node-RED - that's what my blog is doing. Stupidly it's become a kind of CMS with all blog pages actually being template nodes in the flows.json - no db nor dashboard involved!
- also there is UIBuilder variation from @TotallyInformation
So there are many different approaches to integrating Node-RED into a non-IoT use case.
But one thing that would interest me (and probably a few others here) is deployment - how scalable and maintainable are Node-RED based solutions? We all know GitHub actions, puppet, chef, ansible, k8s, docker, jenkins and all the rest - how does deploying, updating, improving visual flows fit into those solutions? What's the workflow for having a Node-RED solution at scale?
FlowFuse is one, are there any others?
2 Likes
I will be honest and say I've not done a lot of work with UIBUILDER on mobile. But given that it is relatively tiny compared to both D1 and D2 and because you can code your core front-end using static resources rather than having to have everything delivered dynamically, it should be both scalable and mobile friendly.
Though the default CSS might need some tweaks. If you do spot something that needs tweaking for mobile, please do let me know, I'm always open to suggestions.
You can help scalability further by putting a proxy in front of access to UIBUILDER. This multiplies the scalability due to the reliance on a static core. That proxy can be Cloudflare (or similar) by the way, you don't have to build it yourself.
To help matters further, should you wish to combine the ease/flexibility of a no-/low-code generated front end with uibuilder's static core, you can simply create a static update from your dynamic outputs by using the uib-html and uib-save nodes. This is great for parts of your web app that might only change occasionally. Even something like an hourly updated weather forecast would be ideal for this approach.
My own recommendation here is "don't get carried away". Just because you can use Node-RED, doesn't mean that you necessarily should. Node-RED is great for prototyping as well so there's that. But where I've seen it used in anger commercially falls into 2 categories. They are both related I think. At scale, I've seen it deployed as an ETL (Extract, Transformation, and Load) and integration hub. Then there is the IoT type where it is deployed to support specialist hardware for sensors and controllers.
Both of these are really back-end uses rather than user-facing to be honest.
I think that the largest front-end use I'm aware of is the Flight Tracker.
So clearly, Node-RED can scale to some degree anyway but I don't think we should ever forget that Node-RED is a bit of a (friendly) monster. It is big and complex because it is a "general purpose" development tool. This is not a criticism, just an observation I've made before. Using it do deliver a fully dynamic UI to thousands or more simultaneous users would be something that I would personally be VERY reluctant to do professionally. This was always one of my guiding factors in the development of UIBUILDER (which is now the longest-serving Node-RED UI other than http-in/-response nodes 
Having been going over 10 years with many more ahead of it) - use the native capabilities of HTTP, HTML, CSS and JavaScript as much as possible, just make it easier. Also, enable people to use existing web development workflows as far as possible.
One last point about uibuilder - you can deliver all your static assets including the uibuilder front-end library from a completely separate and high performance web server if you like. So you could leverage your existing, highly-scalable, web infrastructure and use the comms channel back to Node-RED just for data exchange.
Node-RED is "just" a Node.js app at the end of the day. Self hosting, either on-prem or in the cloud, is simple and effective. It is used by many commercial organisations and was deployed at scale to help management of NHS England's infrastructure by ATOS when they were our previous solutions partner.
@Tim99 Any success in adding this to a Github repository as Colin suggested?
some nitpicking:
but at the same time:
I think those two statements are contradictory - if Node-RED is "just" a NodeJs app and NodeJS is Turing complete, that means Node-RED can solve any problem that a Turing complete machine can - just that it does it visually 
So my recommendation would be get carried away and find other applications of Node-RED to bring Node-RED to a broader audience. Hence transporting the ideas of flow based programming to a broader audience.
I come from the Ruby world and people were amazed when Elixir came out: it is Ruby syntax on top of Erlang. Erlang was - until then - a programming language used for telecommunication boxes. These two things had nothing to do with each other (Ruby being renowned for Ruby On Rails, i.e. web) but why did it happen? Because Ruby has really really really bad at concurrency (at the time) and Erlang is fantastic at currency. Erlang has really really really bad coding syntax (it's prolog like) and Ruby has really nice syntax sugar. One is functional language, the other object oriented. Yet Elixir was an immediate success and remains so.
This would not have happened hadn't someone not tried it out.
I believe the same could happen for the concept of flow based programming (FBP) - the underlying concept of NR. The concept has been around for years yet has not found broader traction* even though its proven to work really well (see unix pipes if you doubt that).
Now to bring everything together: the problem that FBP has is that it's complex and hard to understand, the same problem that Erlang has. Elixir and Node-RED have in common that at the heart of both them are complex and hard-to-understand concepts yet both of them manage to bring a certain amount of simplification to those concepts.
Just as Elixir makes functional concurrent programming simpler, so does the visual approach of Node-RED for flow based programming. Unix pipes aren't a simple approach to FBP but Node-RED is.
*=Broader traction in the sense of programming concepts: we have object orient, list processing, prolog, functional, procedural, .... but where does flow based programming come in?
(having written this, I would love to create a Erlang backend for Node-RED - advantage: true concurrency instead of the fake single-threaded NodeJS event-driven environment .... and Node-RED brings event-driven paradigm to the functional concurrency of Erlang .... Erlang-RED!)
I didn't say "we can't". 
We were talking about scalability and I'm assuming that mostly means commercial/production scale.
Absolutely Node-RED can do just about anything you want. But whether it is the best tool for a specific job is another thing entirely, right?
And I totally agree with you.
BUT, as with any complex tool, you need to understand its limitations. Just because I own a hammer, not everything becomes instantly a nail - though my DIY skills are at such a low level, I'd probably try anyway!
And I think I already said that Node-RED is a great prototyping tool.
It has been a very long time indeed since I last looked at Erlang, and longer still since I looked at Prolog! However, Node.js already has true multi-threading. It is a relatively low-level API I suppose, however it certainly exists and is easy enough to use. Worker threads build on that as in the browser. Integration to other compiled libraries could also be used of course, mostly via NAPI right now, and those can also be multi-threaded of course.
However, we are now a VERY long way away from the topic of this thread.
So was Ruby back in the day - just spin off worker threads[2] and throw tasks at it. Erlang has this built in to the language, no need for the overhead (and source of errors) of managing a worker thread. So I would argue NodeJS is multi-process not multi-threading.
Simple example of what I mean:
As it stands, Node-RED/NodeJS will execute actions 1,2,3 sequentially* since NodeJS is single threaded. Now, I could create a worker thread and have these things running in parallel - I don't want the extra work.
What I want is that the underlying engine does this for me and that is done - IMHO - simpler with Erlang than NodeJS. Node-RED does everything so that things can run in parallel but then the underlying engine doesn't support it.
*=Very quickly because of the event driven nature of NodeJS but sequentially.
[2] = delayed_job was one of the first. What it required was a job queue and a process picking jobs off the queue. This meant a database was required that acted as a queue store. The typical use case was sending emails generated by a web request. The main app writes a job into the database, the worker process reads off a job and executes it. Since jobs are independent and the database has ACID protection, multiple worker processes could be started to add compute. Scalability for workers is a no-brainer.
To do the same (sending email from a http request) in Node-RED:
Done. No worker thread, no database, no extra moving parts.
Of course since NodeJS isn't truly multi-threaded, this can actually delay the response to the http request even thought it shouldn't. With a truly multi-threaded language this won't happen.
It's Saturday, no one is reading anyway!
Yes they are!! 
3 Likes
Trying to find time. Will do ASAP
1 Like
I have managed to upload the Mobile App Node-RED export to GitHub 
Here is the link to the repository.
ToDoList Code
Many Thanks Tim
1 Like
