Where does one find the definitive guide on integrating back end C++ (or other language) classes in order to do complex business logic in the "background"?
Best practices? Practical advice? I work primarily in C++ (Qt).
Have a look at how you can create C++ Addons in Node.js - https://nodejs.org/api/addons.html
This allows you to create a module in C++ that can be loaded with require into a node.js module. So you first create your C++ module, then wrap it in node.js to create a Node-RED node in the palette - https://nodered.org/docs/creating-nodes/
We don't have a node-red specific guide for doing the C++ part as its beyond the scope of our documentation.
1 Like
Marvelous! Thank you for the direction. I have a few use cases already that I can work on as I learn. Much appreciated.
Isn't nodejs inherently single threaded, so the C++ module would not actually operate in the background, or are there ways around this?
"background" is not a literal threading term here.
OK, so what you want to do is to include C++ code in a node instead of using javascript.
Your question was the reason for MY query. What options exist then? The Node.js add-on makes sense, and appears to be a "callback" sort of arrangement which is sensible for asynchronous data producers/consumers.
Part of the question revolves around being able to encapsulate logic in compiled programs for various reasons. Some of those reasons involve information security and encryption key management, which would not be looked at favorably by a certification agency if implemented in JavaScript in plain text on a "web server".
So while a "key management" application might be a Node.js/Red front end, the back end that drives the key management business logic needs to be as obfuscated as it can possibly be. Additionally, any key management/logic libraries that might be provided for a specific application will likely be C++ and "untouchable".
It was more of a statement of what I understood you meant rather than a question. Doesn't @knolleary's suggestion do the job?
Yes, I believe it does. I think I have such a library that I can wrap and test with Node.js. It should prove interesting and turn some heads.
Thank you both for pitching in.
Just idle curiosity here, but does the Addon have to be wrapped in a contributed node, or can it be loaded with require in settings.js and used in a function node?
1 Like
Yes it could be. The Addons are loaded using require and the code loading it is completely unaware of whether it was implemented in JavaScript or otherwise.
1 Like
Thanks, Nick. That opens interesting possibilities, since I have bits of legacy C code that NR talks to by TCP or MQTT. It's not worth changing those, but if I run into similar situations in the future, I might sit down and study the API.
Time to go down some Node.js rabbit holes it sounds like 
Node is incredibly powerful and flexible.
Yup. I still feel like I've gone through the looking-glass, where JavaScript is a Mad Hatter's tea party full of odd and inconsistent programming ideas. Learning to go with the flow (pun intended).
2 Likes
I would be a bit worried about the maintenance 'costs' of this route. I can't help thinking that using MQTT or similar as an interface might be much simpler and you wouldn't be worried about changes with nodejs version and so on. Perhaps it wouldn't be that bad though, more learning would be required to fully understand the implications.
An advantage of MQTT is that you get multi-threading, but there would obviously be run time overheads, so it depends on the requirement.
Apparently, one of the options for implementing Addons (N-API) is intended to survive changes in the JS engine and not require re-compilation for new versions of node.js. That's all I "know" on the subject. I'll be watching to see what @guitarpicva can produce.
From a support perspective, my deployed systems would rarely change their versions of any underlying tools.
Part of why I am going down this thought road is to assess the viability of Node Red as a customer deployed system which includes hardware and software. The people in the particular market I serve generally are not systems people to any great degree. To them this would be a black box that does magic.
It appears that my resistance to JavaScript menagerie has come to an abrupt end as well.
1 Like
Do remember though that server-side JavaScript is still a fast-moving arena so you will find yourself needing to update things perhaps more often that you had previously. This is especially true if your systems cross network boundaries and particularly if they are accessible from the Internet.
Are client browser changes the target of that warning or only the server side??
I should also clarify that "key management" has nothing to do with web api's or authentication. This is straight up encryption of data being transmitted by other means outside the internet. None of the systems I refer to would necessarily even be internet connected.
The server. Node.js is still updated very regularly with important fixes including security fixes. Similarly node.js modules (including Node-RED modules) are updated very rapidly. Even more so now that people are regularly getting security warnings about their modules from GitHub and other sources. Also partly due to the large number of modules the average module includes so that the dependency map is very deep.
While it is great that things are being kept current and regularly updated, it can cause a bit of a headache for an administrator.
Not a big problem generally, just something to be aware of if you are used to slow-moving developments.
1 Like
