For the past year, I've been deeply immersed in an experiment: creating a node-based visual automation tool for Odoo. What started as a learning journey has evolved into Nuido (and later Nuido 2, or N2), a custom framework that powers several specialized applications, including AI chat pipelines and general automation workflows.
In this post, I'll reflect on the technical journey so far—particularly the key decisions, challenges, and lessons that led me to conclude the first iteration of N2.
Understanding Node-Based User Interfaces
Node-based UIs share a remarkably consistent core structure, regardless of the application:
- A canvas/workspace area
- A list of available node types
- A menu or toolbar
Variations mostly stem from layout choices (e.g., persistent side panels vs. contextual popups) and, more importantly, the tool's purpose.
General-purpose diagramming tools like draw.io or Visio tend to be feature-rich and complex. Specialized tools—such as chatbot builders—can afford to be simpler, often needing only a handful of connection types.
My initial goal was twofold: build a node editor for AI chat pipelines (later called AI Chat Studio) and a general automation app (Nuido Flow). This dual focus heavily influenced early design decisions.
Since I'm not a UI/UX expert, my approach was pragmatic: I wanted all node parameters visible directly on the canvas—no clicking into separate panels to configure them. This sounded convenient at the time, but it introduced significant layout and spacing challenges.
For AI Chat Studio, I envisioned nodes with labeled sections for specific connection types. For Nuido Flow, generic input/output ports felt more appropriate.
Rather than building two separate implementations, I opted to create a shared base library that could support both styles. This decision marked the true beginning of the project.
Building a Node-Based UI in Odoo: From Scratch or Libraries?
Odoo's frontend is built on Owl, its custom JavaScript framework. Most existing node-based libraries (Rete.js, LiteGraph, etc.) are either pure JavaScript or tied to React/Vue—none were Owl-native.
My realistic options were:
- Integrate a pure JS library
- Build everything from scratch
General diagramming libraries come with extensive features I wasn't sure I'd need. Learning yet another framework on top of an unfamiliar application type felt risky. So, I chose to build from scratch.
(If you're interested in the implementation details, I've documented much of the process in previous videos on my channel.)
Key Frontend Lessons
- Math and Geometry Are Essential
- Even basic features require solid geometric understanding. Simple straight lines are easy, but anything more advanced—Bezier curves, proper arrowhead placement, edge routing—relies on concepts like the Pythagorean theorem and vector math. A circular node is straightforward (fixed radius), but rectangular nodes vary the distance from center to edge depending on direction. Without grasping these basics, edge rendering quickly becomes unreliable.
- Clear Goals and Planning Matter
- I started with a "let's see what happens" mindset, prioritizing learning over polish. This worked for exploration but led to rework—like realizing AI Chat Studio could live inside the general workflow app, making its specialized node design unnecessary.
- Owl Can Handle It
- It's absolutely possible to build a functional node editor purely in Owl: drag-and-drop, connections, panning, zooming—all work smoothly.
The Backend: Another From-Scratch Decision
Similar dilemma on the Python side: existing visual programming libraries were either standalone or overly complex.
I again chose to build from scratch, resulting in Nuido's core execution engine.
The simplest viable approach won: a registry mapping where nodes are defined by class names (as strings), instantiated dynamically, and executed via dynamic function calls. This keeps interpretation straightforward while leveraging Odoo's existing structure.
For specific apps:
- AI features relied on external libraries (no choice there)
- Automation nodes mostly wrapped existing Odoo capabilities (crons for scheduling, custom controllers for webhooks, etc.)
Over time, I added nodes for templating (Jinja), GraphQL, Shopify integration, AI-structured output, automated emails, and more. The node-based approach started feeling truly natural for Odoo automation.
Why Nuido 2 (N2) Exists
Despite progress, Nuido's editor remained basic. I wanted standard features: keyboard shortcuts, undo/redo, minimap, better usability overall.
Two major pain points emerged:
- Parameter-Heavy Nodes vs. Workspace Real Estate
- Showing all parameters directly on nodes consumes significant space. On large screens with simple flows, it's fine. On smaller screens with complex workflows, the canvas feels cramped fast. Pan/zoom helps, but doesn't solve the root issue.
- State Management for Advanced Features
- My original object-oriented approach (nodes as Owl components + model classes) made implementing undo/redo cumbersome—it would require heavy serialization layers that felt forced.
These issues prompted N2: a redesigned frontend with a different architectural approach.
Additional improvements in N2:
- Auto-layout to reduce manual node arrangement
- Redesigned styles with tighter margins
- Future plan: a configuration button for nodes—show common parameters on-canvas, advanced ones in a dialog/panel (best of both worlds)
Additional N2 Insights
- Nodes don't have to be class-based. In N2, I switched to schema-based nodes using Zod for validation and Immer.js for immutable state—proving multiple valid approaches exist within Owl.
- Trade-offs are inevitable. Owl excels at many things but wasn't built for node editors. Mixing tools and accepting compromises is part of the process.
Showcasing N2's Potential
The new modules built on N2 highlight what's possible:
- N2 Action & Triggers: Modular workflows, custom server actions as nodes, model methods as triggers—pointing toward true low-code automation.
- UI Customization: Limited but practical form tweaks (headers, buttons, status bars).
- N2 Forecast: Statistical forecasting fits naturally—scheduled execution and parameter tuning directly on canvas.
- N2 AI & AI Chat: More flexible RAG nodes, supporting any Odoo model as retrieval source (with newer libraries).
This last point brings an important lesson: power amplifies risk.
Even though workflows execute under user context (preserving Odoo's access controls), improper setup can expose sensitive data—especially when feeding it to public-facing AI assistants. N2 AI forces manual field selection to mitigate this, but no safeguard is foolproof.
Great power comes with great responsibility.
Closing the First Iteration
With these reflections, I'm marking the end of N2's first major iteration.
Thank you to everyone who has starred the repositories, subscribed to the channel, and followed along on this experimental journey. Your support means a lot.