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.
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.