I think there are quite a few folks here who, like me, develop APIs and libraries in their day jobs. We're faced with similar choices about which third-party components to include, and often there isn't any easy way to tell which is going to be supported and maintained for the next 10 years, and which will be abandoned next week. (Well, apart maybe from the basic Windows and Linux toolchains and libs )
You really just have to look at the past history, whether it's a big company or small (or solo) team, how often it gets updated etc. and try to make an educated guess.
The same pretty much applies here, and it's how I'm approaching my choices as a hobbyist Node-RED user - if the node or flow I'm planning to use has a lot of downloads, is frequently updated, and the author is a regular poster, then there's a good chance it's going to be around for a while. If it hasn't had an update for a couple of years, then it may not be a good choice.
And of course, half the fun of developing stuff is fixing it when it breaks - or is that just me being weird?
Definitely most of the fun for me, though one of my production instances runs a paging system that routes messages to the right pagers/phones for codes at a hospital; code-blue, code 180 (stroke) and the like. If it were to ever totally break, I'd care more about restoring operation quickly than about how much fun I'm having. I've moved that particular instance to core nodes only over the last couple revisions (and tested flow imports using the projects feature and our internal git repository) to ensure only maintainers I trust are in my toolbox. It's what got me navel-gazing on this topic.
Well, I can fully understand that, and I'd be exactly the same. Luckily I don't have that kind of pressure in my work, and don't use Node-RED in a production environment, just C, C++ and occasional assembler.
Aye, testing is a vital part of development that unfortunately often gets overlooked. It's also something that doesn't seem to be taught these days either.
I transitioned to the healthcare world from the storage world. It blows my mind on a regular basis how little attention some vendors I work with today pay to testing compared to how thorough and precise it was in my SAN-guy days. Yeah, it sucks to lose corporate data, but you can't restore a human being from backup (yet.)
Testing is one of the things I love this platform for, though. It's super easy to keep a live flow up, split the data feed, and A/B test the ever-loving crap out of new versions before going live. It's also taught me a better appreciation for properly crafting debug logs... edge cases just love to spring up when you least expect and end-users never complain as much as I wish they would.
Well, I'm mainly in the national admin side of healthcare so more corporate than clinical but I'd agree, very few people pay attention to the consequences of choices made in the IT world, many of which don't come from IT but from people with a "little" knowledge.
Last week I had to step in and deal with a request from a new national body who were requesting 50 Chrome addins to be added to the secure desktop build. Not only would that have slowed the browser to a crawl but it would have exposed a lot of sensitive data to 3rd-party websites and services over which we have no knowledge or control. This is the same organisation that have publicly stated that "only Google know how to do Digital"! And they are setting the policies for healthcare IT in the UK!
Anyway, back on topic. Good comments on production IT issues guys and hopefully an insight for those who don't normally get involved with that side of things.
What I do is to use the contrib nodes to develop the initial solution and see how that is working. Then as a second step, for those contrib nodes "in doubt", or "need some improvement/change", replace them with nodejs modules implemented in function nodes. Those nodejs modules are used in a much larger communities an as result have been tested more, receive more frequent updates, some are also "officially supported".
This does require programming the new function nodes and this takes a little effort, but the original flow doesn't change much or is improved.
I find that by using the additional contrib nodes, it really helps to could get a good idea what I want to improve / change using the custom build nodes with nodejs, to improve the total solution, speeding up the development time. So even if those original contrib nodes do not make it to "production", they did help shape "production"!
)
