Discussion about a new Dashboard

Dashboard
1

In case anyone is not aware - the Node-RED Dashboard is built upon Angular v1. This is going End Of Life (EOL) at the end of this year (December 2021) - and from then on will receive no updates. This means that any security holes or other issues from then on will not be fixed and so could possibly affect Node-RED-Dashboard. I say possibly because not all vulnerabilities may be exploitable due to the way we wrap up the angular libraries, but it is up to individual users to satisfy themseleves as to this.

We (I) fully intend to maintain Node-RED Dashboard beyond this date with small updates, fixes, suggestions, etc - but users have to be aware that it may get exposed at any time, and it may not be possible to fix. Users must do their own due diligence to assess their level of risk for any continued use, for example usage within a closed network may well be fine, but we cannot provide individual advice and guidance.

This means that we should also look to what other paths there are for a future Node-RED Dashboard. So I would invite everyone to contribute to the discsussion.

As usual there are several aspects to the discussion, some philosophical, some technical, and some practical.

  • Should there even be a single Node-RED project owned Dashboard ?
    - or should we just support 3rd party dashboards ?
    - Julian's Ui-builder has always deliberately been much lower level than Dashboard precisly to allow people to bring their own tooling to the party and give them full flexibility - BUT it does mean a much steeper learning ramp and (currently) there is no easy "set of widgets" on-ramp.
    - Thorstens Flexdash (Demo | FlexDash web dashboard) - is another approach showing much promise - but again it is not multiple different widgets in the flow (maybe this is a good thing ? or not ?)

  • or work with other dashboard projects ?
    - such as https://www.appsmith.com/ - as they have many more developers than we do.
    - any others that could be considered ? Any Node-RED "friendly" ones ?

  • underlying concern - long term commitment to project.
    - core team can't commit to a ground up new dashboard due to all existing commitments.

  • Is the current (lots of UI widgets) / some minimal layout tooling the right way to do it ?
    - should the Dashboard be a more separate tool - with better layout controls, eg allow sub-groups of widgets to be reused - etc - but a single pipe back to core. If so then it would need to be able to support adding extra widgets.
    - should it be more integrated ? (the editor IS a dashboard :slight_smile:

  • Current deficiencies (just a few :slight_smile:
    - single user only
    - chart easily overwhealmed with too much data (out of memory crash)
    - chart widget not enough options
    - fixing layout can be confusing / too complicated
    - can't use ui widgets in subflows (to make re-useable ui elements)

  • Other
    - are there any great dashboarding type libraries out there that anyone is aware of (we may have missed)
    - should we tie ourselves to another library (like Vue or ???)
    - or "go back" to raw html/css - see First september give-away (let's create one gauge)

What are your thoughts ? All ideas and opinions welcome.

6 Likes
3

As you know, uibuilder was always a base framework and there has always been the intent to build higher layers on top. I have done some very simple examples but more work would, of course be needed.

I based uibuilder on VueJS predominantly as this showed the most promise and greatest flexibility with minimal boilerplate. But of course, you can use any framework. Svelte, for example shows great promise.

So if someone(s) were to focus on the higher-level stuff and I focused on the lower-level, that would immediately give a broader development base.

So that is one possible approach. Build a higher-level framework over the top of uibuilder. That framework could itself be in two layers. A mid layer could focus on the components and I've already made some moves to make components easier to create and manage across multiple packages. The top layer could focus on the actual GUI builder.

My fear for Node-RED if you follow some of the other dashboard projects would be getting into the same position as you are now with a large, mostly monolithic core codebase only maintainable by 1 person.

Something like Appsmith or one of the other GUI builders might provide the top-level of a future dashboard of course which could greatly reduce future risks.

Whichever approach is taken, I would certainly advise ensuring that it is broken into different areas that can be more simply maintained.

I would say not, for the reasons given above. The current code, even after your own stewardship, is arcane, and complex. Code is passed around in ways that don't really fit in with modern web tooling or best practice which adds to the complexity of new components and leaves them tightly coupled to Dashboard making the move to a new generation difficult.

Yes! (But I would say that because it is how uibuilder is architected :grinning: )

Decoupled components allow growth and change without destabilising the whole.

No! The editor is complex enough as it is. Also, I know that separation of the editor from the runtime is being looked at and further integration would surely inhibit that?

At the end of the day, Node-RED is a SERVER, a web Dashboard should be clearly a client. With Node-RED's excellent comms capabilities sat between the 2.

I don't know that you realistically have a lot of choice. You need to give support to component developers so that they don't have to do the whole DOM thing by hand otherwise every component will work differently and it will certainly never be performant.

Just don't chose one as arcane as Angular! My current favourites are certainly VueJS still. It is still growing and has fantastic and growing support. And yet it isn't overly complex either. If you want to do simple things, you can do them simply, without even needing a build step.

Also Svelte which I see has tremendous potential though is still quite young.

REACT of course must also be considered if only due to the breadth of support that it has (though last I looked Vue was growing faster).

For the same reason given above, I believe this would be a real mistake. A good front-end framework does the heavy-lifting in a consistent way but doesn't get in the way (one of Angular's faults). It uses best practices and benefits from a dedicated development input that continues to improve performance, and stability not just feature bloat.

A good framework is also modular, allowing change to happen in uncoupled ways.

4 Likes
4

Node red for a basically unskilled programmer is an answer to our prayers. We can create a fairly robust project with little code. Not having a dashboard is extremely problematic on a lot of levels. As pointed out there are a few other dashboards available to use. Interestingly, I was considering the situation about "outside" nodes and their use. More than a few times I have tried to use "non core" nodes only to discover they don't work and are basically abandoned. When I get into that situation I can usually create a function node to do what I need but it takes a lot of work, research and help from the forum. My concern with using the dashboards mentioned is that somewhere down the road those projects may be abandoned as well. My feeling is that the node red team should have some type of dashboard available as part of the node red core code. My dashboards aren't cute or pretty but they do function and that is enough for me. For those who are really code proficient and can do the html or whatever code that is fine but not really an option for me. So when you say that the dashboard is going away I panicked. So to finish I think for the long run something built into node red is essential even if it means that your options are limited.

9 Likes
5

To me, it only seems natural to build something on top of the uibuilder. We haven't really used uibuilder in projects yet, but totally will after reading this news.

6

I must confess that we started using Node-RED because of the dashboard. The dashboard is easy to use and can show live data conveniently.

Current dashboard has its limitations too. Besides the slow real-time chart issue, one big problem with the current dashboard is the auto-scaling. If user changes screen resolution, then the current layout does not work typically.

My vote goes to Uibuilder (Vue.js) based Dashboard. The new dashboard should be more dynamic that allows user to configure easily. A Vue.js based dashboard scales well with different screens. Still, it should be very easy to use. Ideally, users with the current dashboard can grasp the new dashboard quickly.

1 Like
7

Hi Dave,

Thanks for starting a discussion about this issue!

I will give my feedback from point of view of a (UI) node developer. It is about the same feedback that I gave recently to Thorsten (@tve) when discussing his Flexdash:

I have spent a tremendous amount of free time on developing a series UI nodes. It would be VERY painful for me personally, if I had to put everything into the garbage bin. I could "try" to find time to migrate my stuff one time to another dashboard. But that is only possible if that dashboard would behave a bit similar (= control the widget via input messages & send output messages based on user input). Of course I don't expect it to fully compliant with the current dashboard! But if it would work entirly different, then there is no way I can migrate all my nodes due to a lack of free time. And there is also no option for me to support multiple dashboards.

I really like stuff like the node-red-contrib-image-output node, although that is not obeying the "the flow editor is not a dashboard rule". I confess... But that is only to simplify debugging my flows. For me that is more than enough dashboard stuff inside the flow editor.

So not sure what good advice to give here, since I don't have experience with other web technologies.
However it would be nice if we had one "standard" dashboard, for which we can develop stuff. And that you know for sure when you use that dashboard, that you also have the stuff from other Node-RED ui developers at your disposal. But unfortunately I can't give any advice about which way to go...

P.S. I don't expect the core team to develop/maintain such a dashboard...

8

I personally think having something closely integrated with Node-RED is a must.
What I’d like to see is a dashboard where you can drag and drop widgets from the dashboard itself.

When I do UIs using Dashboard it’s usually because I need to make something very quickly, that’s why I stayed away from uibuilder until now.
When we need to do something more polished we usually do it independently in React and use MQTT to communicate between the dashboard and Node-RED.

4 Likes
9

I agree. The ability to do layout changes on the actual layout using drag-and-drop has to be the ultimate match for Node-RED.

If you use uibuilder for the base framework, you don't need to mess with MQTT connections from your clients as uibuilder provides the websocket connection to Node-RED. Use uibuilder with REACT, it works just fine. :grinning:

1 Like
10

Our react apps often communicate with other applications as well (Unity, Touch Designer) so that’s why we usually keep it independent from Node-RED.

1 Like
11

We took on node-red-dashboard when its original creator wasn't able to continue maintaining it. We inherited a lot of design decisions that we wouldn't have made if starting from a blank page. But it was much better than having nothing. It's also true to say the majority of its continued development and maintenance has been thanks to @dceejay - and I think we all owe him a big thanks for keeping it going this long.

Any successor dashboard project has to learn from the lessons of the current dashboard - along with the other contrib dashboards that have come (and gone) along the way.

I don't think there is an existing natural successor to node-red-dashboard that offers the same ease of use it has. UIBuilder is great if you know what you're doing when it comes to front-end development, but we must not lose sight that one of the primary audiences of the existing dashboard are users who are not code developers.

Whether UIBuilder can be layered up to provide a complete low-code solution is an interesting question. I don't know enough about it to judge whether that would be a good fit or not.

Personally, I prefer the 'a node is a widget on the page' conceptual model of the current dashboard. It fits well with the model of installing extra nodes in the palette to gain extra widgets. Being able to send data to a specific widget, or handle the click of a button directly in a flow just feels right to me. Having a single node represent the whole pipe between NR and the dashboard can lead to some messy wiring.

From a low-code perspective, one of the main shortcomings of the current dashboard is the lack of good layout tooling. The non-responsive grid layout was something we inherited and certainly something any new dashboard needs to handle much better. The group-layout tooling helped somewhat, but it isn't exactly the most intuitive WYSIWYG tool.

It wasn't arcane when the original contrib-ui project was created. And that's an important consideration with any approach that exposes an underlying library; that library will continue to evolve independently of what we do and we either keep up, or face another end-of-life situation further down the line.

Another common question we get is about multi-user dashboards. I think there are two (at least) different models to consider:

  1. a dashboard that provides a view of physical state of something - such as home automation or an industrial controller. In that case, the state is independent of the user - a light is on or off regardless of who is logged in. But different users could have different levels of access to different parts of the dashboard.

  2. a dashboard that provides a view into a database - where the data it displays depends on who the user access the dashboard it.

I would hope to find an approach that could support either of those models - whilst maintaining the low-code ease of use.

Unfortunately, with Angular reach its end of life, this is something that is out of our hands. But I want to reiterate what Dave said - we are not throwing node-red-dashboard in the bin. So any nodes that have been created for it will continue to be useful for some time yet.

But we do have to start this conversation about what comes next to serve us for the next N years. If there was any way to seamlessly migrate to some new underlying library without any disruption, we wouldn't be having this conversation. We've already had to make some painful decisions ourselves - work had been underway to add proper support for Dashboard nodes within subflows - so you could create reusable components. That's now on hold until we figure out the plan.

11 Likes
12

Does Angular v2 totally break everything making it impractical to move the dashboard to it? I've found the dashboard to be really useful despite its warts. My usage is local network only so I'll be standing pat for now, haven't even updated to node-red v2 -- if it ain't broke, don't fix it!

13

The latest Angular is version 12. If dashboard is still based on Angular, then we should go for the latest stable release. :grin: Angular 1 was released without thinking about mobile device, which is also a problem of the current dashboard. Angular 2 targets for mobile device already. But it is totally different from 1.

Here is a picture of comparison. So any direction we go, it should get better. Just don't stand still (It will be a slow death) :grinning_face_with_smiling_eyes:

Comparison-table-Angular-vs.-React-vs.-Vue
Comparison-table-Angular-vs.-React-vs.-Vue851Ă—526 23.3 KB

4 Likes
14

I am very pleased that you guys have started this discussion. And I also want to thank Dave and others that kept the current dashboard alive during all those years!!!!

And I want to say that I agree with every word you wrote above! Very nice to hear your opinion. Especially since it matches 100% my expectations :slight_smile:

I don't expect the core team to lead this, but hopefully now some frontend developers can join forces to see if something like that is possible. I don't care if it is a new frontend or an existing one. I have not followed those technologies, so can't judge at all...

4 Likes
15

Could the API easily be decoupled from the current dashboard-node and being freed from the legacy problems?

16

It isn't so much about that particular API.

If we didn't care about contrib nodes, we could pretty much reimplement all of our nodes using whatever toolkit we wanted completely under the covers. The ui_template node would be broken because that exposes angular directly to the user.

But we do have contrib nodes to consider. They have to use some sort of toolkit for their ui. We have to be somewhat opinionated as to what that is.

2 Likes
17

In my opinion there should be core-team maintained node to support easy to build dashboard. Current dashboard has gone a bit too far.
To be widely open for any level of usage, it should only provide messaging and may be some layout base and an API to plug in components. Couple of simple examples how to make primitive component will be enough for community to start building and the best solution grows up naturally.

3 Likes
18

Totally agree and that's what I meant in my comment above. Plus I am sure there are many gems from the uibuilder project which could be used.

19

I disagree. If the dashboard doesn't provide a set of standard widgets then it's of little use. You end up with fragmentation with little consistency in user experience. Well end up with a dozen 'button' modules, each one published to add just one more feature the others don't have. That doesn't help end users.

Of course there's a discussion over what that core set should be. But it has to be useful out of the box.

5 Likes
20

To avoid that, node candidates should go through an approval process and then be tagged as "official" ui node :slight_smile:

1 Like
21

@knolleary is correct I think in there needs to be a robust set of core nodes, enough to get a decent dashboard, whatever that may look like. Depending on a volunteer community for basic functionality invites chaos. Yes there are numerous talented contributors today but who knows what that will look like tomorrow. Node Red out of the box needs to be self sufficient or the attraction to non proficient coders diminishes considerably. Those with the skills have the ability to create their own dashboard anyway.

1 Like