I Built a Zero-Dependency Visual JSON Flow Editor in Vanilla JS for the Camino Flow Engine

#architecture #springboot #spring #caminoengine

A few days ago, I introduced Camino-a lightweight, rule-driven JSON flow engine for Java.
📖 Stop Hardcoding Your Workflows: Meet the Rule-Driven JSON Flow Engine for Java

The goal of Camino was simple: give Spring Boot developers an alternative to heavyweight BPMN tools like Camunda or Flowable. Instead of dealing with massive XML files, steep learning curves, and database bloat, Camino lets you map your service layer execution dynamically using a clean, readable JSON structure and MVEL expressions.

But there was a catch. As your business logic scales, hand-writing nested JSON arrays with exact id and nextId references gets tedious. You lose the "visual map" aspect that makes traditional BPMN tools so appealing to system architects and business analysts.

I needed a way to visually design these JSON flows. And because I wanted to keep the "lightweight" philosophy of the Camino engine, I decided to build the frontend without any dependencies. No React. No NPM install.

Meet the Camino Flow Editor-a zero-dependency, Vanilla JS visual canvas for the Camino engine.

The Problem: JSON is for Machines, Visuals are for Humans

When you define a flow in the Camino Java engine, it expects a schema like this:

{
    "name": "myFirstFlow",
    "blocks": [
        {
            "id": "f2966cbd...",
            "type": "START",
            "nextId": "e21464b9..."
        },
        {
            "id": "e21464b9...",
            "name": "checkNameIntersection",
            "type": "INTERSECTION",
            "conditions": [
                { 
                    "name": "yes", 
                    "expression": "name.equals('George')", 
                    "nextId": "3a18a..." },
                { 
                    "name": "no", 
                    "defaultCondition": true, 
                    "nextId": "fa337..." }
            ]
        }
    ]
}

When you define a flow in the Camino Java engine, it expects a schema where blocks are linked by matching IDs. The engine is incredibly flexible-it doesn't care if your IDs are long UUIDs or simple strings like "fetch_user" or "step_1", as long as the nextId property correctly points to the id of the target block.

However, manually maintaining these links in a text editor is a recipe for a typo. The Camino Flow Editor solves this by giving you an infinite drag-and-drop canvas.

When you select a "Target" in the UI, the editor handles the "plumbing"-automatically mapping the relationship between the source and destination IDs. You simply connect the blocks, configure the rules, and click Save. The editor exports the exact JSON schema your Spring Boot backend expects.

How I Built It (Without Frameworks)

Building a node-based visual editor using just HTML, CSS, and Vanilla JS presented some really fun architectural challenges.

1. Compact Canvas & Modal Configuration

One of the issues with visual flow editors is cognitive overload. When every block displays all of its configuration properties, a 10-step flow takes up three monitors.

To solve this, Camino Flow Editor keeps the canvas entirely compact. Blocks only show their Name and Type. All of the heavy lifting-defining the Java AbstractActionHandler names, writing MVEL expressions, and setting fallback "Default" conditions-is tucked away in a dedicated modal window accessible by double-clicking.

2. Dynamic SVG Orthogonal Routing

I wanted smooth, Manhattan-style (orthogonal) routing that stays perfectly vertical or horizontal. Without a heavy library like jsPlumb, I had to build a custom geometry engine.

There is a transparent SVG layer draped over the DOM workspace. Whenever you move a block or change a target dropdown in the config modal, the engine calculates the coordinates, paths around adjacent blocks to prevent "backward loop" overlapping, and draws beautiful 15px-radius rounded corners terminating in an arrowhead.

3. A Deep-Copy History Engine

You can't have a serious editor without Ctrl+Z.

I implemented a comprehensive history stack. The editor takes a lightweight snapshot of the underlying state object before every destructive action (creating a block, deleting one, changing an MVEL expression, or lifting your mouse after a drag). Hit Ctrl+Z to undo or Ctrl+Shift+Z to redo, and the SVG canvas repaints itself instantly.

The Perfect Workflow

With these two projects combined, the workflow is incredibly fast:

Draw it: Open CaminoFlowEditor.html locally. Drag and drop your workflow, add your MVEL routing logic, and click Save.
Drop it: Move the exported .json file into your Spring Boot src/main/resources/camino folder.
Code it: Create your AbstractActionHandler Java classes to match the names you defined in the UI.
Run it: Pass your initial context HashMap to the FlowExecutor, and watch Camino execute your visual map.

No database schemas. No heavy XML parsing. No bloated dependencies. Just pure, decoupled business logic.