# Do you consider it best practice to "keep flows vanilla?"

**URL:** <https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772>\
**Category:** General\
**Created:** [11 November 2019 04:59 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772 "2019-11-11T04:59:16Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![JayDickson](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jaydickson/32/90592_2.png) [@JayDickson](https://discourse.nodered.org/u/JayDickson)\
**Post date:** [11 November 2019 04:59 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/1 "2019-11-11T04:59:16Z")

</div>

I often find myself striving as often as possible to use nodes that come packaged in the initial install on flows that are in production use. This got me wondering if maybe I'm fussing over nothing, or if maybe this could actually be a preferable approach. What are everyone's thoughts on this?

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [11 November 2019 08:38 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/2 "2019-11-11T08:38:20Z")

</div>

Can you clarify a bit what you mean? Do you mean you don't want to use nodes like node-red-dashboard?

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [11 November 2019 08:39 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/3 "2019-11-11T08:39:23Z")

</div>

Well, hard to say. The problem with contributed nodes is whether they will continue to be supported. So it is probably not unreasonable if you are wanting to keep a flow in production for an extended period.

---

<div class="post-metadata">

**Author:** ![kuema](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/kuema/32/6542_2.png) [@kuema](https://discourse.nodered.org/u/kuema)\
**Post date:** [11 November 2019 09:08 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/4 "2019-11-11T09:08:23Z")

</div>

While many tasks are solvable with just the core nodes, you can lose readability of your flows very quickly if they become more complex. And as soon as you rely on third-party systems (databases, custom communication systems, ...) you need to put contrib nodes into place. I wouldn't want to do complex client and connection handling within my flows, but rather put these into reusable custom nodes.

As always, you need to find a trade-off. I try to put an emphasis on flow readability.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [11 November 2019 13:30 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/5 "2019-11-11T13:30:30Z")

</div>

Agree in general, but some nodes aren't really needed when dealing with external API's as just sending the request is nearly as easy and certainly saves you having to keep the nodes up-to-date.

A trade-off for sure.

---

<div class="post-metadata">

**Author:** ![kuema](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/kuema/32/6542_2.png) [@kuema](https://discourse.nodered.org/u/kuema)\
**Post date:** [11 November 2019 13:42 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/6 "2019-11-11T13:42:41Z")

</div>

If it's a "simple", let's say, web-based API, for sure. Vanilla Node-RED will be more than sufficient for that. That's what I like about it. 🙂

But in my job I often have to deal with proprietary protocols, "invented" by our customers with a guarantee for maximum pain, instead of relying on established standards. 😖 So I move all the complex stuff into a nice little node to keep my flows clean from that.

---

<div class="post-metadata">

**Author:** ![JayDickson](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jaydickson/32/90592_2.png) [@JayDickson](https://discourse.nodered.org/u/JayDickson)\
**Post date:** [11 November 2019 14:01 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/7 "2019-11-11T14:01:10Z")

</div>

> [@Colin](#):
>
> Do you mean you don't want to use nodes like node-red-dashboard?

Certain nodes will be unavoidable for certain functionality, and I would include dashboard and uibuilder in that category, but there are plenty of others which provide functionality that's easily (but not quite as easily) achieved using the function node or other core nodes. One that that comes to mind, is [node-red-contrib-string](https://www.npmjs.com/package/node-red-contrib-string). (A personal favorite that would kill some of my older flows if it became unavailable.)

There is [precedent](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/) for such removals to occur, but do you think it's worth actually worrying about?

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [11 November 2019 14:29 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/8 "2019-11-11T14:29:27Z")

</div>

> [@JayDickson](#):
>
> do you think it's worth actually worrying about

Well if you use a contrib node there is always the chance it will lose support and so may become unusable when, for example, nodejs is updated. If you use such nodes then you have to be prepared to replace them if necessary at some time in the future.  
If the worst happens you can always fork it an fix it yourself.  
Some nodes do not have their source on github and personally I would not use such a node. Other than that I am happy to use contrib nodes if they save me time.  
Of course if you are in a safety or security critical area then that would be another issue to consider and this might rule out contrib nodes.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [11 November 2019 17:00 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/9 "2019-11-11T17:00:53Z")

</div>

> [@JayDickson](#):
>
> uibuilder

Urg! No pressure there then 😟

> [@JayDickson](#):
>
> There is [precedent](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/) for such removals to occur, but do you think it's worth actually worrying about?

Yes, you _should_ worry about it - at least if you are looking for production quality and longer timespans. And most certainly if your work is commercial.

A lot of contributed nodes come from amateurs or pro developers outside their normal sphere. There are plenty of the current 2,300 nodes that are not actively being developed.

So it does make sense to minimise the number of non-core nodes in use.

It also makes sense to keep forks of all of the nodes that you do rely on so that you know for sure you have a copy of them that you can periodically update if their original updates. In that case, you can fall back onto your own instance quite easily by updating the package.json file in your userDir folder so that it points at your own version.

---

<div class="post-metadata">

**Author:** ![Trying\_to\_learn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/trying_to_learn/32/28400_2.png) [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)\
**Post date:** [11 November 2019 21:43 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/10 "2019-11-11T21:43:44Z")

</div>

I'll stick my neck out here.

I agree that trying to use supplied nodes as much as possible.

It has been said that if you only use these nodes: flows can become unreadable (or look ugly).

On that, maybe you you could use subflows as macros to simplify parts of the flow where this "messy look" happens.  
Alas there is a problem that subflows only allow one input.  
Though that can be worked around with a bit of work.

There is the statement that third party nodes may not continue with support.  
Yeah, ok. But that's with anything, in some way or another.  
If the node works and does something I am slightly at a loss why it would need ongoing support.  
Granted things may happen which need new problems to be solved, but again shall say that goes for anything.

There is a line to how much of them you use.

Ok, this post isn't really helping. I'll shut up.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [11 November 2019 22:04 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/11 "2019-11-11T22:04:44Z")

</div>

> [@Trying\_to\_learn](#):
>
> Yeah, ok. But that's with anything, in some way or another.  
> If the node works and does something I am slightly at a loss why it would need ongoing support.

ll we are saying here is that the nature of who uses and writes for Node-RED and the wider node.js environment tends to result in somewhat higher levels of dropped support.

In addition, the node.js and Node-RED environment is comparatively fast moving. Coupled with the fact that you often end up with dozens of sub-packages, there tends to be a higher rate of obsolescence and security failures than average. That means in turn that packages may need to be updated more often than you might otherwise expect.

With uibuilder for example, VueJS and bootstrap-vue are being updated several times a month on average. So if I don't keep updating it, it may fall too far behind in updates resulting in extensions not working or security holes.

> [@Trying\_to\_learn](#):
>
> Ok, this post isn't really helping. I'll shut up.

No, the dialogue is useful.

---

<div class="post-metadata">

**Author:** ![Trying\_to\_learn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/trying_to_learn/32/28400_2.png) [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)\
**Post date:** [11 November 2019 22:12 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/12 "2019-11-11T22:12:56Z")

</div>

Yeah, ok. I get that.

But one of my "favourite" nodes is the `gate` node. Originally I used the `traffic` node.

This is handy to control message packet flow at given times/reasons.

Though the `function` node can do this, as I have also _been there - done that_ these kind of nodes pop up now and then which have a nicer feel to them.

I fully agree that it would not be a good idea to _put all your eggs in one basket_ and heavily reply on a third party node.

But if needs be: a risk assessment needs to be done on the benefits vs problems of using the node.

Sure, I have been caught out a few times, and I am not a rocket scientist. So no multi million dollar rocket was destroyed because of my choices.

I also accept that I am no way near qualified to really give data on viability of nodes and their stability.  
But really at the end of the day it is different from person to person and application to application.

I again feel like I am talking only for the sake of seeing my post. I'll stop here.

> [@TotallyInformation](#):
>
> With uibuilder for example, VueJS and bootstrap-vue are being updated several times a month on average. So if I don't keep updating it, it may fall too far behind in updates resulting in extensions not working or security holes.

(Sorry)

That can be true. But that is only if there are security holes.  
It is also true (well, extending you the knowledge of this over mine) about the extensions not working.

But again: That is an unwritten understanding with anything. Just look at windows and security updates.

I think there is also a difference between things like `uibuilder` and the basic functionality of NR.  
I don't think there is a comparison between `uibuilder` and `gate`.  
(example!)

Maybe I am missing something there. But for "run of the mill" functions third party nodes are good for development of NR in the bigger picture.

Say a lot of people use (again for example everyone uses) the `gate` node.  
This could be taken on as a needed feature and that be taken on board the team to include that (or something which does the same function) in the base model.

Ok, I'll shut up again.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [11 November 2019 22:39 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/13 "2019-11-11T22:39:04Z")

</div>

> [@Trying\_to\_learn](#):
>
> But that is only if there are security holes

Sadly they are as certain as death and taxes!

> [@Trying\_to\_learn](#):
>
> But again: That is an unwritten understanding with anything. Just look at windows and security updates.

Yes, that is why you need to keep updating I'm afraid.

> [@Trying\_to\_learn](#):
>
> Maybe I am missing something there. But for "run of the mill" functions third party nodes are good for development of NR in the bigger picture.

Certainly not missing anything and I'm not suggesting in any way that 3rd-party nodes aren't really good for the Node-RED community as a whole, the more the merrier certainly, how else will we see growth and innovation?

To put this back into perspective, the original question was about approach - for a production environment. That may well mean different things to different people. But overall, it is likely to be something that requires stability over a period of time and may well involve a commercial arrangement with all of the legalities that implies.

In that specific use-case, it makes real sense to think carefully about what, if any, 3rd party nodes you want to include with your product.

For those of us messing around at home and seeing what we can achieve with an amazing tool like Node-RED and its accompanying nodes, it is a different thing altogether. I have 51 nodes in my "new" Node-RED environment and 72 in my "live" environment - that is total nodes rather than installed Node packages. So loads. Typically, I'll update everything at least once a month. Often more.

That isn't always feasible in a production environment.

---

<div class="post-metadata">

**Author:** ![Trying\_to\_learn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/trying_to_learn/32/28400_2.png) [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)\
**Post date:** [11 November 2019 22:53 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/14 "2019-11-11T22:53:12Z")

</div>

> [@TotallyInformation](#):
>
> To put this back into perspective, the original question was about approach - for a production environment. That may well mean different things to different people. But overall, it is likely to be something that requires stability over a period of time and may well involve a commercial arrangement with all of the legalities that implies.
> 
> In that specific use-case, it makes real sense to think carefully about what, if any, 3rd party nodes you want to include with your product.

(It isn't I want to argue, so please don't see it as so.)

Yes, so you are in a production environment.  
You need to achieve "task A".

As such, there is no standard node to do this task.  
You could download a third party node that does what you want at this time, or sit down and build a flow which does it. Slightly complicated.

It does what is needed now.

The future comes and it is needing to be modified.

Option 1 with the imported node: is you have to see if it can be done.  
Option 2 with the _hand written_ flow: Though you have a better understanding of what is going on, you have to rewrite the code to do the new function.

I agree that if you are really of sound programming mind, the second one would be the preferred way.

Option 1 is prone to problems if it has to be rewritten. Not understanding the code as much as if you wrote it yourself is not a good thing.

But that partly depends on the part of the functionality which is to be changed.  
If it specifically involves what that node does, yes you are in for a world of hurt.  
But if it is external to that, I don't see much difference in rewriting the code with the third party node.

Yes, the latter part is a can of worms.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [12 November 2019 00:42 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/15 "2019-11-12T00:42:25Z")

</div>

> [@Trying\_to\_learn](#):
>
> (It isn't I want to argue, so please don't see it as so.)

A Discourse indeed 😃

The Answer is - there is no answer.

As you say, many different approaches which mirrors the original message. Does it make sense to minimise the number of nodes for production use? Yes. Does it _always_ make sense? No. Sometimes it does and sometimes it doesn't.

But now we are headed off into the realms of philosophy and it is high-time for bed.

Good night.

---

<div class="post-metadata">

**Author:** ![kuema](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/kuema/32/6542_2.png) [@kuema](https://discourse.nodered.org/u/kuema)\
**Post date:** [12 November 2019 06:35 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/16 "2019-11-12T06:35:13Z")

</div>

> [@Trying\_to\_learn](#):
>
> You could download a third party node that does what you want at this time, or sit down and build a flow which does it. Slightly complicated.

You are missing the third option, write a node yourself. 😀 Depending on the task, this is even less complicated than putting it into a flow. And the API for that is well-documented, so if you know your way around NodeJS and Javascript, it is pretty easy to dive into.

That's how we use Node-RED at work, more or less as an extensible "middleware" platform to handle the data flow between different systems (PLCs, databases, devices, customer systems, ...). As I wrote earlier, often these customer systems or devices don't provide standard interfaces. There are no third-party nodes for that. So what I do is putting the code into a library (a NodeJS package that can be used and tested separately) doing all the "complicated" stuff in there, and provide wrapper nodes for that library for use in Node-RED.

Node-RED at home is completely different topic. 😀

---

<div class="post-metadata">

**Author:** ![Trying\_to\_learn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/trying_to_learn/32/28400_2.png) [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)\
**Post date:** [12 November 2019 07:41 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/17 "2019-11-12T07:41:24Z")

</div>

> [@kuema](#):
>
> You are missing the third option, write a node yourself.

I didn't really elaborate on the second point, but I did cover it.

> [@Trying\_to\_learn](#):
>
> Option 2 with the _hand written_ flow:

---

<div class="post-metadata">

**Author:** ![kuema](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/kuema/32/6542_2.png) [@kuema](https://discourse.nodered.org/u/kuema)\
**Post date:** [12 November 2019 09:49 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/18 "2019-11-12T09:49:55Z")

</div>

Ah, okay. But then you should have written hand written _node_, not _flow_. 🤓

Sorry, I'm a bit picky about terminology. Bad habit. 😂

---

<div class="post-metadata">

**Author:** ![JayDickson](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jaydickson/32/90592_2.png) [@JayDickson](https://discourse.nodered.org/u/JayDickson)\
**Post date:** [12 November 2019 13:48 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/19 "2019-11-12T13:48:03Z")

</div>

> [@TotallyInformation](#):
>
> But now we are headed off into the realms of philosophy

Exactly where I hoped this would go.

---

<div class="post-metadata">

**Author:** ![Trying\_to\_learn](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/trying_to_learn/32/28400_2.png) [@Trying\_to\_learn](https://discourse.nodered.org/u/Trying_to_learn)\
**Post date:** [12 November 2019 19:30 UTC](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772/20 "2019-11-12T19:30:02Z")

</div>

> [@kuema](#):
>
> Ah, okay. But then you should have written hand written _node_ , not _flow_ .

Yes, ok. But I did mean flow, but in saying that, I believed it encompassed nodes as well.

My bad.

Nothing wrong with your habit.

[Next page](https://discourse.nodered.org/t/do-you-consider-it-best-practice-to-keep-flows-vanilla/17772.md?page=2)