Visual Builder Overview

Why a visual canvas instead of a text editor

A hand-written backend hides its own shape — you have to read through route files, middleware, and service calls to reconstruct how a request actually flows through the system. A node graph makes that shape the primary artifact: every API endpoint, database query, business rule and AI call is a node on the canvas, and every arrow between them is a real data dependency you can trace with your eyes instead of grep. Nothing about this trades away control — every workflow you build here is still exportable to real, framework-idiomatic source code once it's ready; see Framework Export.

Nodes, connections, and the canvas

Drag a node onto the canvas, configure its fields in the side panel, and connect it to the nodes around it — that connection is what actually moves data: an output on one node becomes an input on the next, and the whole chain executes in the order the arrows describe. There's no separate wiring file or hidden dependency graph; the canvas is the source of truth for how a request flows through your backend.

A small chain — receive a request, validate it, write it to the database, respond — looks like this on the canvas:

API Endpoint  (POST /orders)
   ↓
Validation    (order body matches schema)
   ↓
SQL           (INSERT INTO orders ...)
   ↓
Response      (201, { orderId })

Every node type — from an API Endpoint to a database query to a call to an AI model — has its own configuration fields, inputs and outputs, documented in full in Nodes. As a project grows, group related chains into separate Workflows — one for authentication, one for orders, one for notifications — instead of one sprawling canvas holding your entire backend.

What you can build with it

Because the node catalog covers HTTP, databases, auth, AI and custom code, the canvas isn't limited to one kind of application — the same building blocks compose into a REST API, an authentication service, a webhook processor, an AI-powered endpoint, or an internal tool. What determines the shape of the result is which nodes you connect and how, not a template you picked at project creation.

Running and debugging in place

Press Run and Fimaflow walks the graph, highlighting each node as it executes — inputs, outputs, timing and logs for every step, right there on the canvas. When a node fails, execution stops there and that node is what's highlighted, with the error attached, instead of a stack trace you have to map back to a file and line number yourself. See Execution and Debugging for exactly what that looks like on a real run.

Designing before building

Fimaflow isn't only a workflow editor — before wiring up nodes, you can sketch your system architecture, and model your database with Entity-Relationship (MERISE) diagrams or document it with UML, in the same application. That keeps planning and implementation in one place instead of a separate diagramming tool whose output you have to manually translate into the actual schema.

Interactions with the rest of the platform

• • A workflow built here is what Framework Export reads to generate a real project — the canvas and the exported code always describe the same graph.
• • Once deployed via Runtime, the same canvas is what you keep editing — a change and a re-deploy, no separate production codebase to keep in sync.
• • An assistant connected through MCP sees the same workflows and can trigger or inspect them the same way you would from the canvas.