Framework Export

Why export instead of just running the workflow

The builder is where you design a backend; export is how you get one you actually own. A node graph is convenient to reason about and iterate on, but it's not something you want as your only copy of a production service — you want files you can read, diff, test, and deploy without depending on Fimaflow being available at runtime. Framework Export turns the graph into exactly that: a normal project in the framework of your choice, generated deterministically from the same nodes and edges you built in the canvas.

Supported frameworks

• • Hono — lightweight, runs great on Bun and edge runtimes.
• • Express — the most widely used Node.js framework.
• • Fastify — performance-focused Node.js framework.
• • Elysia — Bun-native, end-to-end type safety.
• • FastAPI — Python, for teams standardized on a Python stack.

Every export follows the idioms of the framework you picked — routes, middleware and project structure look like what you'd expect from a developer who wrote it by hand in that framework, not a generic template stretched across all of them. Pick based on where the project has to run and who maintains it afterward, not on which one Fimaflow makes "easiest" — the generated code is equally complete for any target.

• • Deploying to an existing Node.js team's infrastructure → Express or Fastify, whichever they already standardize on.
• • Running on Bun, or wanting the smallest generated footprint → Hono or Elysia.
• • A Python-only infrastructure team, or existing FastAPI services to sit alongside → FastAPI.

How the generation works

Export walks the workflow's nodes and edges once and translates each node type to the construct it maps to in the target framework — an API Endpoint node becomes a route handler, a SQL node becomes a parameterized query using that framework's usual database client, an Auth node becomes middleware wired ahead of the routes it protects. Edges become the call order inside the generated handler, in the same sequence they run on the canvas.

From the builder: open the workflow, choose Export, pick a framework, and download the generated project as a zip. From the terminal, the same operation is one command:

fimaflow export <workflow-id> --target hono --out ./backend

See CLI for authentication and CI usage of this command.

What gets generated

• • Route handlers for every API Endpoint node, at the exact endpointMethod/endpointPath configured — see REST APIs.
• • Database access matching your SQL/Database nodes, using the framework's idiomatic client (e.g. pg for Express/Fastify targets, asyncpg for FastAPI) instead of a Fimaflow-specific abstraction.
• • Authentication middleware matching your Auth nodes — see Authentication.
• • A .env.example listing every environment variable your workflow references, unset — see Environment Variables.
• • A Dockerfile — see Docker Export

As a concrete example, a two-node chain — an API Endpoint at GET /orders/:id feeding a SQL SELECT — exports to Hono as roughly this handler, in a real, editable file under src/routes/orders.ts:

app.get("/orders/:id", async (c) => {
  const { id } = c.req.param();
  const result = await db.query(
    "SELECT * FROM orders WHERE id = $1",
    [id]
  );
  return c.json(result.rows[0] ?? null);
});

Fully editable, always

The generated project is plain source code — readable, formatted, and yours to modify. Add a dependency, tweak a handler, wire up your own CI — nothing about the export process expects you to keep it untouched, and nothing in the generated code calls back into Fimaflow at runtime.

Interactions with the rest of the platform

• • Export reads the workflow's current saved state — unsaved canvas changes aren't included until you save.
• • Custom Code and Function nodes are copied into the generated project close to verbatim, translated only where the surrounding framework glue requires it (e.g. how the handler receives its input).
• • Re-exporting after changing frameworks produces an entirely new project — it does not migrate a previous export in place.

Limitations

• • Export doesn't merge hand-edits back into the workflow — if you edit the generated project directly, keep iterating on that codebase rather than re-exporting and expecting your edits to survive.
• • A workflow using a node type without a mapping for the chosen framework fails the export with the offending node named in the error, rather than silently omitting it.