Websockets - Runtime API V2


Hi all,

One of the reasons for migrating from my old FBP framework to NRed, was the intensive use of websockets for IPC'S.

I can't undestand the scope of websockets in the v2-api .

I have some NR projects on production for customers where is impossible use WS (localhost interface included).

Any suggestion in advance ?

Thanks !!



Sorry, not sure what you mean here by the "scope"?

Why? What specifically makes it impossible?



With scope I mean if the wsockets are necessary only for the communication between the editor and the runtime, or if on the contrary the new runtime itself needs wsockets in some way.

In the first case, it would not have a problem because it could be developed with the local editor and then upload the flows. (this is how I do it now).

Regarding the impossibility of lifting websockets:

  • for physical reasons, some service providers do not allow using (websockets, udp traffic, etc)
  • For security reasons I do not use websockets in desktop nodejs applications.

Obviously I'm not talking about the websockets of a web browser, but ipcs on the same machine to run flows and interact with them from the outside.

Thank you



@selo the new runtime api will not introduce any new usage of websockets within the internals of Node-RED.



It is understood,
Thank you.



OK, that makes more sense now.

When using Node-RED as part of a set of services on the same server, you don't need to use websockets. You can, for example, use UNIX sockets, or indeed direct UDP/TCP as desired.

Once you need to reach across servers, you can still use TCP directly. Or simply create your own HTTP(S) REST API's.

Or, better still in a production environment, why not use a message queue?

Each of these have advantages and disadvantages depending on need and the environment.



@TotallyInformation Thanks for the info.
Well, really my question came from the announcement about the developers about the execution timeAPI V2. Where it is said:

"Do not treat this as a fully documented public application - it's a working document

This is a snapshot (March 2018) of the entire HTTP and WebSocket interface between the editor and the runtime and how it correlates with the internal parts of the runtime.

This has been done to help rationalize internal allocations and help stabilize the API. "


That is why I wanted to dispel all doubt that the use of wsockets of the new API is only for communication with the editor.

This is not so "esoteric", some nodejs applications communicate for example with an embedded web-driver, through websockets within the same app. However, although it is transparent to the user, the fact is that machine ports have been opened.

Thank you all.