[salviati]

I'd be happy to take your experience into account in case I'll need to vouch this in the future.

But unfortunately it's not very clear what shortcomings of Node-Red were a problem for you.

Could you rephrase your experience, focusing on what you believe Node-Red does wrong?

[bearjaws]

1. Workflow builder is cumbersome at scale, it's often hard for anyone to jump in to understand what is going on exactly. Especially if you cannot avoid using a JS node to perform a more tricky manipulation.

2. Often times you end up writing code to help support node-red, you must avoid this at all costs because you end up shifting more and more into code bases, making node-red pointless.

2. Lots of sub menu "advanced" functions that you will need to use for any complex flow.

3. Observability is poor out of the box, especially if you use a service like datadog or NewRelic, we ended up using a catch all error handler that just shipped events to NewRelic.

4. Poor out of box defaults for security, mainly authentication

5. Conflict resolution sucks, you have to JSON stable stringify the changes to ensure you can deal with conflicts and conduct proper code reviews.

[knolleary]

Node-RED project lead here :wave:

That's all useful feedback to us. There's always a balance to be had between putting lots of code in Function nodes and the visual complexity of doing the equivalent in pure nodes. Part of that is understanding where users are falling back to JS in a Function node - and what could the core nodes provide to avoid that necessity.

Code reviews are a common piece of feedback and something we need to help with.

In the day job (FlowFuse CTO) we're looking at how to improve the overall developer UX of Node-RED - both within node-red, but also how you manage it within a team and at scale.

If you had any more feedback on your experiences, would love to hear it.

[daniel-payne]

the issue of code reviews is a problem in standard node-red, the flows.json does not lend its self to git management. I wrote an integration between node-red and vs-code, it's in the node-red forum and the comment bellow.

It fixes this problem, and also fixes a problem of integrating with test tools and code coverage tools.

It's the old 80/20 rule, 80% can be done very quickly with easy to configure out of the box nodes, but it's the last 20% of functionality that takes all the time.

Dropping out to vs-code for this 20% improved my productivity a lot.

TBH I don't know how I would do a code review with n8n, i will need to do more investigation.

[bojan]

I'm also interested in this. My workplace is looking into this, and my intuition says no, but I'd really like to hear other people's experiences, both positive and negative ones.

[daniel-payne]

this is from a post on the node-red forum, and a solution i made.

Once you start to get big and complicated with node-red you will have this issue. But the rest of node-red is fantastic. It also covers a fix for git code reviews and integration with external testing frameworks.

--------------------------------------------------------

I hope this can help anybody having the same issues as I have when writing long functions in node-red editor.

Coding anything over 50 lines become difficult to work with, or trying to view multiple functions at the same time. The rest of node-red is fantastic!

----------------------------------------------------

https://github.com/daniel-payne/functions-templates-manager