DEV Community: Alexandros Korovesis

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

Alexandros Korovesis — Sat, 28 Mar 2026 13:40:53 +0000

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.

Try It Out!

Both the Java Engine and the Flow Editor are completely open-source. I would love for you to try them out, fork them, and let me know what you think!

If you missed the deep dive into how the backend engine works, check out the original article here:
📖 Stop Hardcoding Your Workflows: Meet the Rule-Driven JSON Flow Engine for Java

🎨 Frontend Editor: [https://github.com/a-koro/CaminoFlowEditor]
⚙️ Java Backend Engine: [https://github.com/a-koro/camino]
🚀 Working Demo: [https://github.com/a-koro/caminoDemoApplication]

Stop Hardcoding Your Workflows: Meet the Rule-Driven JSON Flow Engine for Java

Alexandros Korovesis — Thu, 12 Mar 2026 08:00:34 +0000

Managing complex business processes in Java often leads to "Service Layer Bloat." You know the feeling: one service method that calls five others, with complex branching logic and error handling that's impossible to visualize.

I decided to build a lightweight library to solve this: a JSON-based engine that treats your business logic as a dynamic map rather than a static script.

The Problem: Rigid Workflows vs. "Heavy" Alternatives
Usually, if you want to change the order of two operations or add a conditional check, you have to modify the Java code, recompile, and redeploy.

Why not just use BPMN?
Many enterprise developers turn to BPMN (like Camunda or Flowable) for these problems. While powerful, BPMN comes with significant baggage:

Heavyweight Libraries: They often require complex database schemas, massive dependencies, and a lot of boilerplate to set up.
Not Truly Human-Readable: While the diagrams look nice, the underlying XML is a nightmare to read, version control, or manually edit.
Steep Learning Curve: You often need specialized training just to configure the engine.

I wanted something lightweight, JSON-native, and Spring-friendly.

The Solution.
Camino allows you to define a "Flow" as a series of Blocks in a JSON file.

1. Add Camino to your application
Download the camino code from https://github.com/a-koro/camino , build it locally and add the dependency in your pom file.

<dependency>
    <groupId>com.korovesys</groupId>
    <artifactId>camino</artifactId>
    <version>1.0.1-SNAPSHOT</version>
</dependency>

2. Define the Flow
A Camino JSON flow defines a logical sequence using four primary block types: START, ACTION, INTERSECTION, and END.

There is also a dedicate Camino Flow Editor you can download and run in any browser: https://github.com/a-koro/CaminoFlowEditor
Editor guide: https://dev.to/korove_sys/i-built-a-zero-dependency-visual-json-flow-editor-in-vanilla-js-for-the-camino-flow-engine-j1g

By default, flow files are located in the Maven-standard resource directory src/main/resources/camino .

To customize this location, update the following property in your configuration camino.path=/your/custom/path .

Here's a snippet where we check a user's name before deciding which action to take (condition expressions use MVEL):

{
    "name": "myFirstFlow",
    "blocks": [
        {
            "id": "1",
            "type": "START",
            "nextId": "2"
        },
        {
            "id": "2",
            "name": "getNameFromIdAction",
            "type": "ACTION",
            "action": "getNameFromIdActionHandler",
            "nextId": "3"
        },
        {
            "id": "3",
            "name": "checkNameIntersection",
            "type": "INTERSECTION",
            "conditions": [
                {
                    "name": "yes",
                    "expression": "name.equals('George')",
                    "nextId": "4"
                },
                {
                    "name": "no",
                    "defaultCondition": true,
                    "nextId": "5"
                }
            ]
        },
        {
            "id": "4",
            "name": "updateUserAction",
            "type": "ACTION",
            "action": "updateUserActionHandler",
            "nextId": "6"
        },
        {
            "id": "5",
            "name": "informUserAction",
            "type": "ACTION",
            "action": "informUserActionHandler",
            "nextId": "6"
        },
        {
            "id": "6",
            "type": "END"
        }
    ]
}

3. Implement the Logic
You don't lose the power of Java. You start the execution of the flow as defined in your JSON file by calling the FlowExecutor method execute and passing as parameters the name of the flow and a map to carry all your data (process context). The same map will be used to evaluate each condition in your flow with the provided key.

For every ACTION in your JSON, you simply create a class that extends AbstractActionHandler and declare the bean using the same name from the corresponding "action" property.

You process context is propagated in each action in the flow as a HashMap and can me accessed from the ctx property of the execute method.
Finally use this map to construct the response data.

public class GetNameFromIdActionHandler extends AbstractActionHandler {

    @Override
    public void execute(HashMap<String, Object> ctx) {
        System.out.println("executing get name from ID action handler");
    }
}

    @Bean
    public GetNameFromIdActionHandler getNameFromIdActionHandler() {
        return new GetNameFromIdActionHandler();
    }

4. Enable the library
Add spring.camino.enabled=true to your application properties file.

Final Thoughts

Hardcoding business logic into your Java services creates a rigid architecture that's expensive to change. By adopting a flow-based approach, you give your application the flexibility to grow alongside your business requirements.

⭐️ Check it out on GitHub: https://github.com/a-koro/camino
🚀 See the demo: https://github.com/a-koro/caminoDemoApplication