collaborate on multi-user node-red?

[Mike Blackstock]

From trawling the group it looks like several people have raised the issue of multiple users accessing node-red in different contexts, including myself. Toby Jaffey may have been one of the first where he raised the desire to allow his users to use node-red for data processing in his system. There have been other discussions about collaborative flow development

https://groups.google.com/forum/#!searchin/node-red/Integrating/node-red/yyvR27BEG1M/_OXCKVgHWEAJ

https://groups.google.com/forum/#!searchin/node-red/multi-user/node-red/PZan0GvdgoQ/CPh64BXhw_cJ

https://groups.google.com/forum/#!searchin/node-red/multi-user/node-red/CFAdsSEU1L8/eD5t5Ocb_RMJ

Nick clarified that Node-RED has been developed as a single user system and has suggested that we consider a runtime that spawns node-red instances. "My inclination is to not make the core node-red runtime multi-user aware as there are a number of issues with that model - it would be too easy for one user's flows to adversely affect the performance of another user's for example. My preferred approach is a runtime that can spawn individual node-red instances on a per-user basis, with the UI updated to be user-aware.”

Toward addressing this we’ve been we’re working on a couple of prototypes to address the scenario where we would like a single system (device, server, or cluster) to host multiple user’s flows. One use case is to make it really easy for people to spin up their own Node-RED in the cloud for integration and backend processing.

The first prototype was developed by Alexander Futász (cc'd) for Fraunhofer FOKUS institute in Berlin. This prototype does use a single Node-RED instance for deploying flows from multiple users, which works, and surprisingly isn’t that much of a big change to Node-RED itself. Of course the possible performance problem with one flow affecting others mentioned above is evident here. An open task for this prototype is also the pub/sub comms system which isn’t yet multi-user aware as it needs to track websockets per user. The guys from Fraunhofer are interested in multi-user and collaborating for this feature to hit upstream as they also want/need a cloud deploy feature for Node-RED.

A second prototype I've been working on takes Nick’s suggestion and implements a front end run time that manages separate processes, spawning one Node-RED instance for each user. The front end manages security for the instances proxying communications for the UI and access to HTTP inputs to flows.  It can be developed independently from Node-RED allowing it to evolve.  This seems to work well, but is more resource hungry.

Our question to the community is whether there are other approaches to consider, and whether others are working on this issue.  If so, is there an appetite to collaborate on a solution? 

[pawel.m...@spartez.com]

Maybe I'm missing the point here but when you have stateless nodes and whole context in one message object does it really a problem? Whole "user data" is in that one object which travels in flow diagram. As I understand as long as you have truly stateless nodes there can be as many objects as you want to and they shouldn't interfere with each other. If I'm wrong then please correct me. I believe some real-life example will be helpful to make this topic easier to understand.

[Nicholas O'Leary]

Pawel,

you are right to say the nodes are stateless and they do not interfere with each others data. The problem, however, is that even though they are stateless, they do share one thing in common - they run in the same, single-threaded node.js runtime. If a user creates a Function node that takes 300ms to process each message that passes through, that will block the entire runtime and will have a material effect on the performance of everyone's flows in the runtime.

Nick

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

[pawel.m...@spartez.com]

Thank you for your reply, now it's clear. Some time ago I heard about JXCore project (http://jxcore.com/home), I've never tried it but maybe it's worth the shot.

[Mike Blackstock]

Pawel, thanks for pointing out jxcore - it does look like it may be useful.

Another issue is that it is possible for function nodes to share state between them using global context (http://nodered.org/docs/writing-functions.html).

Mike

[pawel.m...@spartez.com]

We use global context only for storing references to external libraries like MomentJS because we want our nodes to be truly stateless - I believe this is good practice to follow.

Please let us know if you have any luck with JXCore.

[Su Steven]

Hi ，  I come from centibox.io , I have develop my multi-user  node-red , using Docker container build different node process/context. I think this is a way solved multi-user global context problem

[Mike Blackstock]

Thanks for this - using Docker containers seems like a nice way forward, definitely a lot less overhead than a new VM.

We've made good progress supporting multiple users with node-red in separate processes.  I'm hoping to have something ready for the community to try soon.  If you're interested in seeing what we're up to, let me know.

I did try jxcore in our project, and while it was easy to spin up node-red in their threads, there didn't seem to be any savings in terms of memory use.  My understanding is that it creates a new node.js VM for each thread.

Mike

[Nicholas O'Leary]

Mike,

I mentioned in the deploy thread earlier that the next piece of work for 0.10 is improved admin/editor security. Part of that is making the editor user aware (if enabled) with login screen etc. But the runtime remains single user.

Will be sharing more of the details when I get a chance.

Nick

[Mike Blackstock]

Thanks Nick -  I caught that but appreciate the heads up.  Our system creates separate node-red run times for each user.  I'm hoping we can leverage your work by allowing others to collaborate in the runtimes we manage.  Look forward to learning more.

[Su Steven]

Hi  Mike,

    I begin my work with small team, we want create mulit-user designer+runtime , off course base Node-Red, we plan 2105 Q2 beta.

any about node-red mulit-user topic I am interested :p

 
在 2015年1月17日星期六 UTC+8上午3:23:35，Mike Blackstock写道：

[Mark Setrem]

Now that's a long term plan!

[Drasko DRASKOVIC]

Hello,

what is the current state of this?

I saw a service like this: https://fred.sensetecnic.com/. Are they firing up a separate NodeRed Docker for each user?

BR,

Drasko 

[William Bradee]

There is also a service from AT&T called Flow Designer, https://flow.att.io/users/sign_in 

It is based on Node-Red