N8n vs. node-red(daniel-payne-keldan-systems.medium.com)
daniel-payne-keldan-systems.medium.com
N8n vs. node-red
https://daniel-payne-keldan-systems.medium.com/n8n-vs-node-red-485e8382b971
68 comments
Licensing is always a critical consideration.
The licenses may or may not be an issue depending if you are using it as is, locally, and to what extent.
The clause is if you're substantially using n8n for your solution. As long as it's partial (which it almost always is)... it's another thing.
Anyone who tries to use one workflow tool exclusively (n8n, node-red) almost always ends up needing to add other tools around it to do what n8n, node-red can't do well. For example handling more than direct AI calls.
n8n is more of a business process tool long before AI came out, and it's useful AI functionality is an addition, not the core source of the product. I see their license in terms of that since they are a more detailed competitor to zapier.
In the beginning using it for personal or small workloads helps keep costs down. When you start making money you need a supported production instance, either you're paying as an owner yourself to do it, or there is the hosted version.
Self hosting traditionally has been for enterprise, but I think startups doing it could be reflected in licenses in the future too.
node-red is great too, but is a slightly different tool.
The licenses may or may not be an issue depending if you are using it as is, locally, and to what extent.
The clause is if you're substantially using n8n for your solution. As long as it's partial (which it almost always is)... it's another thing.
Anyone who tries to use one workflow tool exclusively (n8n, node-red) almost always ends up needing to add other tools around it to do what n8n, node-red can't do well. For example handling more than direct AI calls.
n8n is more of a business process tool long before AI came out, and it's useful AI functionality is an addition, not the core source of the product. I see their license in terms of that since they are a more detailed competitor to zapier.
In the beginning using it for personal or small workloads helps keep costs down. When you start making money you need a supported production instance, either you're paying as an owner yourself to do it, or there is the hosted version.
Self hosting traditionally has been for enterprise, but I think startups doing it could be reflected in licenses in the future too.
node-red is great too, but is a slightly different tool.
> The clause is if you're substantially using n8n for your solution. As long as it's partial (which it almost always is)... it's another thing.
That’s not true at all. This is the relevant part of the license:
> You may use or modify the software only for your own internal business purposes or for non-commercial or personal use. You may distribute the software or provide it to others only if you do so free of charge for non-commercial purposes.
It has absolutely nothing to do with substantial vs partial, it has to do with commercial vs non-commercial and internal vs external.
> In the beginning using it for personal or small workloads helps keep costs down.
If you use it for small workloads and charge money for users to do that, you will be in breach of the license. Do not do this. It doesn’t matter how big or small the workload is.
> Self hosting traditionally has been for enterprise, but I think startups doing it could be reflected in licenses in the future too.
They explicitly switched to this license because they wanted to restrict commercial use. We were a startup and they quoted us $50k for a commercial license. There’s no need to speculate about this. This is not an oversight. This is what they deliberately chose.
That’s not true at all. This is the relevant part of the license:
> You may use or modify the software only for your own internal business purposes or for non-commercial or personal use. You may distribute the software or provide it to others only if you do so free of charge for non-commercial purposes.
It has absolutely nothing to do with substantial vs partial, it has to do with commercial vs non-commercial and internal vs external.
> In the beginning using it for personal or small workloads helps keep costs down.
If you use it for small workloads and charge money for users to do that, you will be in breach of the license. Do not do this. It doesn’t matter how big or small the workload is.
> Self hosting traditionally has been for enterprise, but I think startups doing it could be reflected in licenses in the future too.
They explicitly switched to this license because they wanted to restrict commercial use. We were a startup and they quoted us $50k for a commercial license. There’s no need to speculate about this. This is not an oversight. This is what they deliberately chose.
I took a bit of time to figure out how I arrived at the impression I have. Happy to arrive at more clarity collectively, even if it is me.
1. "OR" allows 3 use cases
- internal business purposes (which is commercial behind the scenes),
- non-commercial (this reads to me like if there's customer facing access to n8n, etc),
- personal use (home lab, learning, hobby projects, etc).
For me, the internal business purposes is the first and main reason I would look at it, where n8n is a tool among other tools in the stack all being used for some of their functionality.
From: "Limitations / You may use or modify the software only for your own internal business purposes or for non-commercial or personal use. "
https://github.com/n8n-io/n8n/blob/master/LICENSE.md
2. Substantial - This feels like skinning n8n to make a product is meant to prevent. If there's an existing business solving their issues and either it's not substantially n8n, and the n8n part isn't a product, service, or module being sold, it could be OK.
This reads like if the complex functionality of your solution is being executed in connected systems external to n8n that it helps route through, the weighing of substantial is clearly outside.
"Our license restricts use to "internal business purposes".
In practice this means all use is allowed unless you are selling a product, service, or module in which the value derives entirely or substantially from n8n functionality. "
---
Small workloads - You are correct in if it was an n8n process being packed and sold, even at small workloads, it could be a licensing issue. Conversely, if the small workload wasn't a process being sold to users.
Commercial quoting - Makes sense, again. If I want to write a workflow in n8n and just skin it, i'm substantially using their software. To me, n8n can't do everything I need so I can't imagine a scenario where that I'd hit that, but absolutely other use cases could. Additionally, the commercial license seems to be for enterprise customers - maybe an option for small business/startup (headcount, or revenue) could be available. Seems reasonable enough, and have seen it with other tools.
If substantial n8n use generated that kind of profit, I'd be happily paying for it to make sure it sticks around and is supported. It's like having an entire n8n dev team to keep n8n running for less than the cost of a developer. But I'm not there.
For me, it's rare that I would rely solely on one tool that heavily. Having base inputs (especially for AI) in text form and feeding it up so different layers could be refactored to other tools over time (such as n8n's orchestration), there can be scenarios where the work is already substantially outside of n8n. At the same time, I look at tools like n8n for what they can do, using them as is, out of the box only, and not modifying them at all, because it then can receive updates.
---
1. "OR" allows 3 use cases
- internal business purposes (which is commercial behind the scenes),
- non-commercial (this reads to me like if there's customer facing access to n8n, etc),
- personal use (home lab, learning, hobby projects, etc).
For me, the internal business purposes is the first and main reason I would look at it, where n8n is a tool among other tools in the stack all being used for some of their functionality.
From: "Limitations / You may use or modify the software only for your own internal business purposes or for non-commercial or personal use. "
https://github.com/n8n-io/n8n/blob/master/LICENSE.md
2. Substantial - This feels like skinning n8n to make a product is meant to prevent. If there's an existing business solving their issues and either it's not substantially n8n, and the n8n part isn't a product, service, or module being sold, it could be OK.
This reads like if the complex functionality of your solution is being executed in connected systems external to n8n that it helps route through, the weighing of substantial is clearly outside.
"Our license restricts use to "internal business purposes".
In practice this means all use is allowed unless you are selling a product, service, or module in which the value derives entirely or substantially from n8n functionality. "
---
Small workloads - You are correct in if it was an n8n process being packed and sold, even at small workloads, it could be a licensing issue. Conversely, if the small workload wasn't a process being sold to users.
Commercial quoting - Makes sense, again. If I want to write a workflow in n8n and just skin it, i'm substantially using their software. To me, n8n can't do everything I need so I can't imagine a scenario where that I'd hit that, but absolutely other use cases could. Additionally, the commercial license seems to be for enterprise customers - maybe an option for small business/startup (headcount, or revenue) could be available. Seems reasonable enough, and have seen it with other tools.
If substantial n8n use generated that kind of profit, I'd be happily paying for it to make sure it sticks around and is supported. It's like having an entire n8n dev team to keep n8n running for less than the cost of a developer. But I'm not there.
For me, it's rare that I would rely solely on one tool that heavily. Having base inputs (especially for AI) in text form and feeding it up so different layers could be refactored to other tools over time (such as n8n's orchestration), there can be scenarios where the work is already substantially outside of n8n. At the same time, I look at tools like n8n for what they can do, using them as is, out of the box only, and not modifying them at all, because it then can receive updates.
---
> Substantial - This feels like skinning n8n to make a product is meant to prevent. If there's an existing business solving their issues and either it's not substantially n8n, and the n8n part isn't a product, service, or module being sold, it could be OK.
It’s not. We wanted to incorporate n8n into our product. It would represent a small, non-essential part of our product. We weren't just skinning and reselling n8n as a product itself. But our users would be directly using an n8n instance hosted by us in a commercial context. I reached out to n8n and was told directly by them that the free license does not allow this and it required a $50k commercial license.
You seem to keep steering the discussion towards “they don’t really mean that”. Yes, they do. These are not unintentional restrictions. They wanted to make these restrictions so they could charge for commercial licenses, so that’s what they did. There is nothing hidden between the lines. There is nothing to figure out. Those are the restrictions.
It’s not. We wanted to incorporate n8n into our product. It would represent a small, non-essential part of our product. We weren't just skinning and reselling n8n as a product itself. But our users would be directly using an n8n instance hosted by us in a commercial context. I reached out to n8n and was told directly by them that the free license does not allow this and it required a $50k commercial license.
You seem to keep steering the discussion towards “they don’t really mean that”. Yes, they do. These are not unintentional restrictions. They wanted to make these restrictions so they could charge for commercial licenses, so that’s what they did. There is nothing hidden between the lines. There is nothing to figure out. Those are the restrictions.
Thankyou for the reminder, long term Node-RED user here, I recently looked again at n8n and wondered why I never took it to far, this is the reason. When you see a git icon and repo it's easy missed.
The license looks quite permissive though as long as you're not using n8n as the platform for your business. According to the license, if you just wrap/productize the flows you create and users don't bring their own n8n credentials or API keys, then you're good. It seems like there's a ton you can build off of it and still stay within the parameters of the license.
Yup. Always makes sense to read the actual license too. I did that today and learned n8n changed their license in 2022. So you could look at the licenses before 2022 as well.
Node-RED project lead here :wave:
As ever, I think each has its strengths and weaknesses, but I know which one I prefer...
In terms of 'out of the box' experience, I do agree there is space for some improved Node-RED nodes to support some of these workflows. There certainly are nodes in the community to help, but there's space for more. And that's an area I think gives Node-RED an advantage; the open source nature that allows anyone to build in the gaps of what's already there. Node-RED provides plenty of low-level building blocks to connect with pretty much anything - but having higher level abstraction nodes is needed to make it more accessible.
It's also an area we're looking at in my day job (FlowFuse CTO) where we provide a commercial platform built around Node-RED.
As ever, I think each has its strengths and weaknesses, but I know which one I prefer...
In terms of 'out of the box' experience, I do agree there is space for some improved Node-RED nodes to support some of these workflows. There certainly are nodes in the community to help, but there's space for more. And that's an area I think gives Node-RED an advantage; the open source nature that allows anyone to build in the gaps of what's already there. Node-RED provides plenty of low-level building blocks to connect with pretty much anything - but having higher level abstraction nodes is needed to make it more accessible.
It's also an area we're looking at in my day job (FlowFuse CTO) where we provide a commercial platform built around Node-RED.
Here i was trying to show the strengths of both, unfortunately Agentic AI is graph based and node-red is flow based. Apples and Oranges.
As a hack, I have got LangGraph working inside of a node-red flow. I will write it up as a medium article in the next few days, as it might be of help to others. It's very codey.
I think production engineers will have to master the Langchain ecosystem, when we creating mission critical AI based systems. I think node-red has good nodes in place to record decisions and data as part of an AI ethics program.
Flowise have a good set of nodes around langchain, but I bet it was a massive and expensive undertaking to build.
Also Dashboard 2 is something n8n is sorely missing and is needed to monotor live systems.
As a hack, I have got LangGraph working inside of a node-red flow. I will write it up as a medium article in the next few days, as it might be of help to others. It's very codey.
I think production engineers will have to master the Langchain ecosystem, when we creating mission critical AI based systems. I think node-red has good nodes in place to record decisions and data as part of an AI ethics program.
Flowise have a good set of nodes around langchain, but I bet it was a massive and expensive undertaking to build.
Also Dashboard 2 is something n8n is sorely missing and is needed to monotor live systems.
You can navigate a graph just fine if you set up flows to iterate through it, just like state machines (there are a few patterns to do that in Node-RED with branching and iteration). It’s perfectly possible.
However, there is something you mention that I think is important - dashboard 2 is still missing critical functionality—for instance, I cannot set it up as the “/“ (homepage) URL in an instance (there’s a lingering bug for that for around a year now) and it is still far from being as well integrated as the original.
However, there is something you mention that I think is important - dashboard 2 is still missing critical functionality—for instance, I cannot set it up as the “/“ (homepage) URL in an instance (there’s a lingering bug for that for around a year now) and it is still far from being as well integrated as the original.
Hey Nick! (See my other comment someplace, which is very closely aligned to your point)
The bit I want to surface in this thread is that there is actually a lot that can be done with sub-flows and custom functions alone (even without added third-party modules) - I built my own library of AI/“agentic” subflows with raw HTTP request nodes and a simple convention for passing LLM context in payloads so I’m a bit biased here, but overall I find Node-RED superior in the amount of control I have over how data is handled.
(Also, I am running Node-RED in bun rather than NodeJS and it is way more efficient, although that means I can’t rely on some third-party nodes, but that is another story)
The bit I want to surface in this thread is that there is actually a lot that can be done with sub-flows and custom functions alone (even without added third-party modules) - I built my own library of AI/“agentic” subflows with raw HTTP request nodes and a simple convention for passing LLM context in payloads so I’m a bit biased here, but overall I find Node-RED superior in the amount of control I have over how data is handled.
(Also, I am running Node-RED in bun rather than NodeJS and it is way more efficient, although that means I can’t rely on some third-party nodes, but that is another story)
I understand nothing of this article.
What does it mean by "n8n" lacks a UI? All it has is a UI, what use cases does the UI not handle? The writing is very poor and does not make sense at all.
What does it mean by "n8n" lacks a UI? All it has is a UI, what use cases does the UI not handle? The writing is very poor and does not make sense at all.
Thanks for reading my article.
Sorry, I should have made myself clearer, I did not mean the UI that you use to create flows with, both systems are drag and drop flow creators. The issues I come across is visualizing what is going on inside of a system once it is created and up and running. I normally would like to have a dashboard showing me what is going on inside of a system. The node-red comes with Dashboard 2 ( a vue based set of components) for displaying whats going on in a live system. But I could not find a similar tool for n8n.
But then n8n has things I am missing from node-red, especially wrappers around LangGraph. I have to code those manually, in a node-red function node and it's not a simple task :(
Sorry, I should have made myself clearer, I did not mean the UI that you use to create flows with, both systems are drag and drop flow creators. The issues I come across is visualizing what is going on inside of a system once it is created and up and running. I normally would like to have a dashboard showing me what is going on inside of a system. The node-red comes with Dashboard 2 ( a vue based set of components) for displaying whats going on in a live system. But I could not find a similar tool for n8n.
But then n8n has things I am missing from node-red, especially wrappers around LangGraph. I have to code those manually, in a node-red function node and it's not a simple task :(
Well not “all” it also has the permanently running workflow engine bit that actually runs the workflows in the background. But yeah same here, very confused about the write up.
n8n doesn't have a customer facing ui.
It's a question that comes up often from low/no-code creators.
It's a question that comes up often from low/no-code creators.
agreed, I'm running it on my localhost right now and it's got a full WYSIWYG interface. This article is slop
thank you for your kind words, I obviously was not clear in how I wrote the article, AI might have picked it up. But I am old school and type everything my self. It's part of the feynman learning process I use.
However I have updated the article so it is much clearer, the UI that is missing from n8n is not WISIWIG, but a management dashboard, to be viewed once the system is live. I have added the following:
"To be clear here, I did not mean the UI that you use to create flows with, both systems are drag and drop flow creators. The issues I come across is visualizing what is going on inside of a system once it is created and up and running."
However I have updated the article so it is much clearer, the UI that is missing from n8n is not WISIWIG, but a management dashboard, to be viewed once the system is live. I have added the following:
"To be clear here, I did not mean the UI that you use to create flows with, both systems are drag and drop flow creators. The issues I come across is visualizing what is going on inside of a system once it is created and up and running."
How did they write their workflows then, in json?
What is an “antigenic AI” or “antigenic workflow” in this context?
It’s used so consistently that I’m not sure if it’s just careless editing or if it’s something new I don’t know about.
It’s used so consistently that I’m not sure if it’s just careless editing or if it’s something new I don’t know about.
sorry, i am Dyslexic, and the spell checker missed this. someone was kind enough to point this out on medium. I have fixed this typo
Obviously it's the nemesis of the heavy metal band Progenic.
https://www.metal-archives.com/bands/Progenic/122279
https://www.metal-archives.com/bands/Progenic/122279
I guess it should be "agentic" but it's used so many times it can't really be a typo...
Seems the writer made a typo in the prompt.
Funny enough, I choose not to use AI to review my stories, as I find it results in an article that is not in my own voice. As i am Dyslexic, I will update this typo.
It was mere speculation on my part, didn't meant it as anything mean.
The article made me check node-red so it did provided something valuable.
The article made me check node-red so it did provided something valuable.
It's clearly a consistent typo and was probably part of the prompt used to generate the article.
I have been using both for a number of years. n8n has had a resurgence recently because of its (quite clever) AI integrations (and it has higher level abstractions for doing workflows), but since I want more control I actually do my stuff (including an AÍ news summarizer and a few “agents”) in Node-RED because once you’ve sorted out your own library for things like API calls, memory, storage, etc. (which I did using just sub flows and custom JS inside them) it can be a lot simpler and more straightforward.
I see n8n as more of “citizen developer” tool (less flexibility, more built-in integrations) and Node-RED as an engineering scratchpad where you can literally build anything you want (for instance, it’s been part of my home automation setup for ages, way before Home Assistant became a thing).
I wouldn’t run _any_ of them as part of an enterprise solution, though. Security, IAM/RBAC, auditability and even general reliability would keep me up at night (even considering that Node-RED runs a surprising amount of small scale on-premises industrial automation, that’s typically in isolated networks, so I’m not factoring those in).
I see n8n as more of “citizen developer” tool (less flexibility, more built-in integrations) and Node-RED as an engineering scratchpad where you can literally build anything you want (for instance, it’s been part of my home automation setup for ages, way before Home Assistant became a thing).
I wouldn’t run _any_ of them as part of an enterprise solution, though. Security, IAM/RBAC, auditability and even general reliability would keep me up at night (even considering that Node-RED runs a surprising amount of small scale on-premises industrial automation, that’s typically in isolated networks, so I’m not factoring those in).
It is worth pointing out that both of them are workflow tools first. The AI agent part is expressed though steps where a model is invoked. This opens the door to a number of issues including vulnerabilities.
My personal, and my I say biased, opinion is that these tools do not deliver on the agentic promise. AI agents require a completely different approach.
My personal, and my I say biased, opinion is that these tools do not deliver on the agentic promise. AI agents require a completely different approach.
The definition of an agent is so vague now. What is the agentic promise and why wouldn't a workflow tool with LLM steps cannot deliver on this promise? Also what vulnerability are you referring to?
I have no stakes in n8n or node red, but being able to embed LLMs in a workflow and conversing with a "workflow" seems to solve a lot of agentic/assistance problems (Make a report of revenue, and send an email report to these people,for example)
What is the completely different approach you are suggesting?
What is the completely different approach you are suggesting?
Beginner here, I sort for agree. I think these tools are good to make a few good demos and quickly sketch something but you hit the ceiling soon where every other thing you do needs more work. There a lot of tutorials online plus the promise of AI automation as the next "get rich quick" thing.
I am curious what is a good tool to build agents these days? I am checking out mastra, someone at the cafe told me about Inngest.. wondering what would you use?
I am curious what is a good tool to build agents these days? I am checking out mastra, someone at the cafe told me about Inngest.. wondering what would you use?
Anthropic recommends not using frameworks and simply writing code against the LLM apis, at least to begin with.
https://www.anthropic.com/engineering/building-effective-age...
https://www.anthropic.com/engineering/building-effective-age...
Check out DBOS. There are a bunch of sample apps here:
https://github.com/dbos-inc/dbos-demo-apps/tree/main/python
DBOS is an open source library that doesn’t require an external server.
https://github.com/dbos-inc/dbos-demo-apps/tree/main/python
DBOS is an open source library that doesn’t require an external server.
If you want to build AI assistants for automating tasks, check out https://nelly.is.
There's a whole n8n subreddit where people are making customer call/customer agent flows.
Think of that what you will but it seems some of them make a profit off of it.
So, it must work somewhat?
Think of that what you will but it seems some of them make a profit off of it.
So, it must work somewhat?
Do these tools still make sense when you can have an agent-type setup like Claude Code or any of the competitors do that kind of low level work?
I know that vibe coding isn't quite there yet, but I wonder if low-code solutions like those are really saving any time at this point. What's the advantage if not velocity?
I know that vibe coding isn't quite there yet, but I wonder if low-code solutions like those are really saving any time at this point. What's the advantage if not velocity?
Haven't used them myself.
But I think it depends on how many built in integrations there are? As if you have a battle tested integration already in place may save writing a script/api.
Also junior devs could be allocated on to it.
But I think it depends on how many built in integrations there are? As if you have a battle tested integration already in place may save writing a script/api.
Also junior devs could be allocated on to it.
It pains me to see all these “node” based automators charging you an arm and a leg. I can’t wait till people see the obvious and just replace them with a few prompts to Claude Code or similar.
I self-host n8n and get a ton of mileage out of it. Doesn't cost me a dime.
Do you use APIs with n8n? Just curious.
If you do, then you might want to factor in the cost of using those as well, including privacy implications.
In my limited testing, I found n8n to be heavily focused on cloud API use, from their onboarding quick tutorial to the collection of provided nodes, I found adapting them to strictly local use something of a chore.
In my limited testing, I found n8n to be heavily focused on cloud API use, from their onboarding quick tutorial to the collection of provided nodes, I found adapting them to strictly local use something of a chore.
There are a lot of nodes that are pre-built to interact with cloud APIs, but you effectively have an HTTP client available that can reach out to any endpoint. In my case, yes, I make use of cloud APIs and realize the trade-offs wrt privacy. You can hit any internal services you like assuming they're reachable from your n8n server
Doesn't cost a dime to host n8n? Or is this only for personal use?
It doesn't cost a dime to host n8n. They even have a docker image prebuilt that you can just pull and play.
It doesn’t cost a dime to host n8n as long as you are only using it internally. If you offer it commercially, then you will have to negotiate a commercial license.
https://docs.n8n.io/sustainable-use-license/#what-is-and-isn...
https://docs.n8n.io/sustainable-use-license/#what-is-and-isn...
Oh, play. Yes, of course.
For production use, it will cost money one way or another.
For production use, it will cost money one way or another.
What n8n gives is a nice gui. They’re going after the people who use Zapier, not the people who use Claude code
true. but the whole point of n8n is that it can call other endpoints. you can use claude code to build those endpoints and just have n8n orchestrate calls
Isn’t there something more native to the AI landscape?
I know both make for excellent all purpose digital glue but would think that’s last resort
I know both make for excellent all purpose digital glue but would think that’s last resort
There is Langflow: https://www.langflow.org
AI native but doesn't feel production ready, I've kept encountering random bugs. I still use it over n8n for prototyping LLM pipelines quick
AI native but doesn't feel production ready, I've kept encountering random bugs. I still use it over n8n for prototyping LLM pipelines quick
I also use FlowiseAI, as a nice GUI over langGraph
> LLMs are non-deterministic; that is each time you run something you might get a different answer.
That's a choice. With (at least) Ollama, you can set the temperature parameter so the results will be deterministic based upon the seed value. Which you can set.
It's used for things like running test cases, but there are likely other uses too.
That's a choice. With (at least) Ollama, you can set the temperature parameter so the results will be deterministic based upon the seed value. Which you can set.
It's used for things like running test cases, but there are likely other uses too.
You are correct about temp and seed, but for some models it still does not guarantee identical answers. Only models explicitly designed for deterministic output can do that, and I am not sure the commercially available models are built like that. I might be wrong.
The thing I was trying to say (not very well) was AI is going to make mistakes.
When we had systems based on relational databases, it was possible to recreate the conditions where the mistake was made. But in a world of LLMs and rapidly changing graph databases, this is almost impossible. So we should be recording everything so we don't make the same mistake twice.
Someone said to me yesterday, "The best doctors have only killed one person." Apparently, it's a common saying in UK healthcare. But it illustrates the point.
I currently work for a bank that is hot on AI ethics; I initially thought it was a bit of HR hype. But as I come to understand the inner workings of these systems, I am thoroughly convinced "recording how decisions are made is just as important as the decisions themselves."
The thing I was trying to say (not very well) was AI is going to make mistakes.
When we had systems based on relational databases, it was possible to recreate the conditions where the mistake was made. But in a world of LLMs and rapidly changing graph databases, this is almost impossible. So we should be recording everything so we don't make the same mistake twice.
Someone said to me yesterday, "The best doctors have only killed one person." Apparently, it's a common saying in UK healthcare. But it illustrates the point.
I currently work for a bank that is hot on AI ethics; I initially thought it was a bit of HR hype. But as I come to understand the inner workings of these systems, I am thoroughly convinced "recording how decisions are made is just as important as the decisions themselves."
Would this be something that Activepieces or Kestra could also do?
https://github.com/activepieces/activepieces https://github.com/kestra-io/kestra
https://github.com/activepieces/activepieces https://github.com/kestra-io/kestra
Neither please god.
We used Node-Red at a previous job for integrating some third party software, total disaster, from upgrading, using JSON for code reviews, to overall performance.
Its a fun toy, leave it at that.
We used Node-Red at a previous job for integrating some third party software, total disaster, from upgrading, using JSON for code reviews, to overall performance.
Its a fun toy, leave it at that.
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?
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?
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.
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.
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.
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.
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.
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.
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.
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
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
I know what you mean about code reviews. I have got that covered,
https://github.com/daniel-payne/functions-templates-manager
https://discourse.nodered.org/t/node-red-and-vs-code-integra...
https://github.com/daniel-payne/functions-templates-manager
https://discourse.nodered.org/t/node-red-and-vs-code-integra...
I’m working on a self-hosted node-red-powered desktop app to connect cloud services to local resources and vice versa. Email me if you’d like to participate in the upcoming beta.
Self-hosted vs cloud is the bigger differentiator here.
They both have cloud and self hosting options, I use self-hosted a lot.
I find n8n is more suited to tying into cloud services. I found n8n a bit more difficult to setup when i wanted to host things on my file system.
Forgive me, the actual differentiator I meant was actually open source (not source available). Been a while since looked at it and found n8n unusable for our needs without a very expensive site license.
if you looking for autonomous agents or RAG pipelines, Dify has a self hosted version.
https://github.com/node-red/node-red/blob/master/LICENSE
https://docs.n8n.io/sustainable-use-license/
We previously looked into integrating n8n but they wanted $50k for a commercial license, which didn’t make sense for us.