Headless mode

[Nicholas O'Leary]

One of the features I've often talked about without having actually implemented is Headless mode - running without the admin ui enabled. This was issue #2 on the list.

I've just pushed a change that finally introduces this mode and has closed off that issue.

If you recall with the last release we introduced the httpAdminRoot and httpNodeRoot configuration settings. This are used to define the root path of their respective http endpoints.

You can now set either of these properties to false (not 'false' the string, but false the boolean type). Doing so effectively turns off their respective endpoints. For ease of use, setting httpRoot to false is a short-cut for setting both httpAdminRoot and httpNodeRoot to false.

Furthermore, if httpAdminRoot and httpNodeRoot are both false (or httpRoot is false), and httpStatic isn't set, then we don't even start the http server.

If you have HTTP-In nodes in a flow and you have httpNodeRoot set to false, you will now get warning messages letting you know those nodes are not accessible.

If you have debug nodes and httpAdminRoot is false, you won't have any access to the debug node output.

Let me know what you think.

Nick

[Luis Montes]

This is an extremely useful feature.

I think it would be nice if we could configure the endpoint to be something other than the originating server.  

Right now loading of the flows is deferred to the d3 library's fetching of the json data via ajax at a relative path.

You might also want to consider ditching ajax altogether for communication to the backend.  Since you're already exposing a websocket to the client for the debug module, you might as well route all traffic as RPC calls through that channel.

This gets us two things:

First, the websocket/RPC is much faster than ajax.

Second, websockets are cross-domain by default, so we don't have to bother with JSONP or CORS to make serving of the client completely detachable from the originating server.

Luis

--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luis Montes]

So a bit more information on this.

I made a branch on my fork that implements full backend/front-end separation and uses websockets instead of ajax for all communication. The net change in code size is pretty small:

https://github.com/monteslu/node-red/tree/websockets

Or for anyone else interested in trying this out:

git clone https://github.com/monteslu/node-red.git

cd node-red

git checkout websockets

npm install

node red

Ok, that's seems no different than the usual, but what's happening is instead of opening up localhost, you can point your browser to the static stuff served up from anywhere, like here:  http://azprogrammer.com/nodered

It will talk to the backend running on your localhost:1880, and speeds up the initialization and usage of the UI by using JSON-RPC calls over a websocket instead of the ajax mappings that were being hit from $.ajax() or d3.json()

I haven't tested everything, and it doesn't implement auth yet, but that should be relatively easy to add as well as some general clean-up.

Also as a simple test to see injecting, code blocks, and debugging are working here's an export of 3 nodes:  https://gist.github.com/monteslu/953d765529a1ead63040

Would love to hear any thoughts on this direction from Nick or anyone else.

Luis

[Nicholas O'Leary]

Hi Luis,

this is some interest work here, but I'm not sure its a direction we want to go right now.

We are not actively looking at separating the UI and runtime, so any discussion of changing the communication between the two is premature. 

More specifically, my primary concern is moving to JSON-RPC over websockets makes the API less accessible to non-javascript environments. I don't think the slight speed up out weighs the fact it moves away from having an http-based API that can be invoked from things as simple as curl. 

Nick

[Luis Montes]

Thanks, Nick.  I appreciate the feedback.

Since multi-tenancy with security is a bit difficult on the backend, I thought it might be nice to at least have it de-coupled from the front-end.  But aside from that, we're already have a websocket dependency with debug, so this changing overall default transports is almost a freebie :)

I'm not using it for this, but I wrote a promises based, client and server JSON-RPC/websockets implementation here:  https://github.com/iceddev/rawr

The idea is that you simply write your server side APIs as javascript functions without worrying too much about whether the transport is REST or JSON-RPC over websockets.

In the case of node-red, it's easy enough to keep the REST route mappings in place that need to be hit outside of the client UI with something like curl.  However the footprint for handling client server communication is actually quite a bit simpler by just defining a function that accepts input and responds to a callback when it isn't something that needs to be a REST call.  The only nodes this really affects are inject and debug since those are interacting with the UI.  The API surface from the viewpoint of a developer working on third party nodes doesn't really change.

Anyway,  I made a little 3 minute video to demo some more functionality this change could enable.

tl;dr 

https://www.youtube.com/watch?v=T45D3sQyhTs

-Luis

[Nicholas O'Leary]

Thanks for the video.

There are some other use cases for near realtime feedback in the ui that are in the early stages of planning - specifically performance figures (# msgs / sec, time spent at each node etc). I'd be concerned about the performance impact of trying to show every single message in the ui, but some level of aggregate information would be more manageable.

So there is a place for a websocket connection back to the server for handling this data - exactly as the debug node does today. Whether an api is created for nodes such as debug to use, rather than each use its own WS connection is a discussion for later.

But, I'm not convinced this should replace the rest api for retrieving/saving flows or the other places rest is used... such as the flow/function/template libraries.

Multi tenancy is another topic for a different day as that isn't in our short term plans. (Not ignoring it, just got lots still to do with the single tenancy model).

Nick

[Luis Montes]

Totally get the concern over emitting everything back to the client.  That's why I throttled it in my demo :)
https://github.com/monteslu/node-red/blob/57bfbc3065db28371a91f1d2c138ae70d211e745/red/nodes.js#L32-L34

Simple rate limit and only send the IDs back on a "pulse" topic.