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.
https://docs.n8n.io/sustainable-use-license/#what-is-and-isn...
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.
The article made me check node-red so it did provided something valuable.
I know both make for excellent all purpose digital glue but would think that’s last resort
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 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?
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.
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.
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?
https://www.anthropic.com/engineering/building-effective-age...
Think of that what you will but it seems some of them make a profit off of it.
So, it must work somewhat?
What is the completely different approach you are suggesting?
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.
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.
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."
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.
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."
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 :(
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.
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?
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!
----------------------------------------------------
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.
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.
https://github.com/daniel-payne/functions-templates-manager
https://discourse.nodered.org/t/node-red-and-vs-code-integra...
https://github.com/activepieces/activepieces https://github.com/kestra-io/kestra
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.
adastra22•5h ago
daniel-payne•5h ago
adastra22•3h ago