Need a "general" advice for a way to go

[sfedo]

Hello everyone,

I'm asking this question here in the community, because people here know a lot about node-red, but also have a lot of experience with different hardware.

I need advice on a way to achieve what I have planned. Luckily there are so many options out there that I just don't know what will get me to the goal.

Ok now to the essentials.
I work mostly with Siemens CPU S7. So far I used node-red for visualization through the dashboard and small manipulation of values from the PLC. Additionally I collected information from other devices and passed it to the PLC. For this, nore-red has been wonderful and I am very satisfied how well, with the help of the community here in the forum, everything has worked out.

Currently I am learning flutter and dart for mobile app development. And I want to be able to control the PLC with the app I'm developing. The app should have user management so that multiple users can control and monitor the PLC with their own interface.

The thinking for this was to use node-red as the backend and receive input from the app and then send it on to the PLC. The same with the incoming values. The PLC sends the values via node-red to the app.

Which component do I need to realize this? What do I need for this?
My considerations are as follows:

• Creation of a rest API which is then accessed by the app and node-red?
• Communication to node-red via MQTT, using raspi as broker?
• Using node-red api, is that possible?
• http requests. not sure what tools i need for this.

Can someone maybe give me a quick guide on what communication path I can take and what tools I need for this?

Due to the fact that there are so many different things, it would be a waste for me to learn anything only to find out later that it is not suitable for my project.

[chrisn-au]

Hi,

Great question - we used Node Red to prototype a set of APIs to a flutter app for a user management app. Node Red is awesome in as much you can get it going extremely quickly. We moved the ‘production’ APIs to GOlang but that was as much about perceived need rather than real

In our case we created a set REST apis to do this

An admin/auth set
A business object set

I would not suggest using mqtt ( although we prototyped using web sockets for real time data flow and it worked surprisingly well)

The Node red admin APIs are used to manager node red and are not appropriate here

So a path forward Example Web REST API with loop through record sets (flow) - Node-RED

For prototyping we secured the api using basic auth however I understand you can do Bearer auth - I just did not get it going

To start with play around with creating a set of get and put (if needed sounds like you are wanting control of the PLC so you will need both) APIs on your local machine. Search google for node-red rest APIs and you will find lots of places to get started . We created two instances of node red (client and server to test)

You will be amazed at how quickly you can prototype

I assume this will be internet connected - you will need to secure your node red instance and provide ssl certificates (again just work but can be a bit tricky to get right)

You can then start to build out your App . You will find dart awesome for this.

So my advice start very simply with two instances of node red talking to each other via rest , add ssl , integrate into dart

Have a look at Serve JSON content : Node-RED

and Example Web REST API with loop through record sets (flow) - Node-RED

To show you how to host and retrieve end points

My 5 cents worth - a very fun project with a bit of a learning curve but you will get there quickly and then you will be astonished with the speed you can iterate -

My last comment if you have never built a rest api before there is lots of great materials on the internet YouTube and others about APIs design . When you first start it seems a bit over kill however you will find a well designed api will save you a lot and is kind of self documenting - so worth the investment

[TotallyInformation]

I agree with Chrisn. Unless you need near real-time 2-way comms, a REST interface is a good way to go because it is a well-trodden path, relatively easy to secure and well supported. Yes, and may be quick to put together. However, a slight word of caution there, in my experience, rushing the design of the API will create many painful delays later on. Spend some time up-front looking at best practice and drawing/writing out the key elements and documenting the schema's.

Node-RED is a great tool for getting going and for playing with different API constructs though so a combination of prototyping and careful thinking through the requirements is perfectly feasible.

As I often do in this forum - possibly much to Nick's annoyance - I will also recommend not just relying on Node-RED to deliver your API even if you decide to stick with it longer term rather than moving it onto GO or RUST for additional performance. As a REST API is "just" HTTP based, you can make full use of HTTP services such as a web server like NGINX or my current favourite, Caddy. I recommend this for several reasons. First being performance, while not likely to get as much of a gain as with more static assets, there is still a good chance that a web server fronting Node-RED will give you some gains with caching. Possibly also load balancing if you need to scale horizontally. Then there is security. Node-RED does of course support some basic (and not so basic in some cases) security directly but it is a complex and fast-moving platform that is not specifically designed for security. So the security part of me says that a front-end tool is a sensible precaution. You can offload HTTPS processing which will certainly give you performance gains (using a multi-threaded web server rather than a single threaded app). You can also offload authentication and authorisation as well. Leaving Node-RED to get on with doing what it does so well.

If you do need near real-time, 2-way comms between your front and back ends, I would actually recommend MQTT. Though it means running yet another service, it is so efficient and so reliable in operation, it seems to me to be well worth the effort and small resource overhead it requires.