Hi! I really like n8n’s simplicity for automation of straight-forward tasks, like reporting or ETL jobs. However, when used for prototype integrations between services via REST APIs, implementing complex logic is quite cumbersome. I mean, adding multiple IFs,SWITCHes and loops gets out of control really easily.
For know, I tend to extract logic into smaller workflows and use Execute workflow node in master flow. It works, but still is not easy to comprehend when your workflow is growing. I have also thought about writing custom nodes, but doing it just for a single workflow is both tedious and violates the DRY and KISS rules.
What I would like to do instead is to put all important nodes on the canvas, configure them one by one and implement all the complex logic inside a code node, dispatching selected nodes from the code itself.
That approach kind of goes against what we have been trying to create, The way I currently handle this is with sub workflows which as you have noticed is tricky to deal with when it comes to managing larger workflows.
We have been talking about ways to make using sub workflows easier so it still wouldn’t be through code but it would be better than it is now. Sadly though I don’t know when any changes on that side will happen so for now the best bet is what you have been doing.
I absolutely understand the reasons to not introduce such functionality as it totally breaks the default convention. Nevertheless, I can forsee some improvements that still follow the graphical way of defining flows, like ability to group and hide several nodes (akin to grouping objects in LabView) as well as extract such group to new workflow and replace it with execute block directly from the canvas. Further improvements could be, for example, showing such “reusable workflows” in node palette (maybe when workflow has some special tag added it could automatically be displayed there?) as well as possibility to define a “schema” in the default trigger node, so it would be easier to check what kind of data structure is required for that subworkflow.
Even just possibility to open workflow in new card directly from the Execute workflow node would be a timesaver
Going back to my original question, I think that just allowing to execute other nodes from the Code node would be beneficial. Such functionality wouldn’t impact the default way of defining workflows, but could enable non-orthodox usage for that small group of people like myself
It could be useful for some but it is not something I am aware of on the roadmap and I suspect something like having reusable workflow chunks that can be quickly seen is more likely to happen.
