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?
Can you clarify a bit what you mean? Do you mean you don't want to use nodes like node-red-dashboard?
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.
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.
2 Likes
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.
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.
2 Likes
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. (A personal favorite that would kill some of my older flows if it became unavailable.)
There is precedent for such removals to occur, but do you think it's worth actually worrying about?
1 Like
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.
1 Like
Urg! No pressure there then 
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.
2 Likes
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.
1 Like
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.
No, the dialogue is useful.
2 Likes
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.
(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.
1 Like
Sadly they are as certain as death and taxes!
Yes, that is why you need to keep updating I'm afraid.
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.
(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.
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.
1 Like
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.
2 Likes
I didn't really elaborate on the second point, but I did cover it.
Ah, okay. But then you should have written hand written node, not flow. 
Sorry, I'm a bit picky about terminology. Bad habit. 
Exactly where I hoped this would go.
2 Likes
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.
