Compressing the Wire: A 94% Payload Reduction in React Flow

Node-graph editors — n8n clones, pipeline builders, anything with connectors and edges — carry a quiet performance leak. The thing the user drags around the canvas is a fat UI object, and naive systems write that object straight to storage. Save a moderately complex workflow and you're archiving measured widths, port geometry, drag state, even framework internals. On IntegrateX that bloat surfaced as sync lag and unnecessary WebSocket chatter during co-editing. I drew a hard serialization boundary, stripped the render-only fields, and the payload fell by 94%.

Where the bytes go

A single React Flow node is not your data. It's your data wrapped in everything the renderer needs: position, measured dimensions, selected and dragging flags, handle definitions, z-index, and whatever view state your custom node component latched onto. Multiply that by every node and edge, serialize the whole graph, and your wire payload becomes mostly things that should never have left the browser. None of it matters to the backend, yet you pay for it on every save, reload, and real-time broadcast — plus the client pays again rehydrating it, which invites render thrash under load.

The Serialization Adapter pattern

The fix is an explicit boundary between two models that the naive design conflates: the render model (what React Flow needs) and the transport model (what your database and wire actually require). An adapter translates between them in both directions, and nothing crosses the boundary without passing through it. In the pattern I call Trinity Architecture, this is the third layer: Presentation (pure React/React Flow views), Reactive State/Orchestration (Zustand, events, optimistic intent), and the Data / Serialization Adapter (shape the lean records for the wire and storage). Boundary rule: the UI never formats DB schemas; the adapter never pokes UI state directly — it only hands records to the orchestrator.

// render model (React Flow) → lean transport record
export function toRecord(node: FlowNode): NodeRecord {
  return {
    id: node.id,
    type: node.type,
    x: round(node.position.x), y: round(node.position.y),
    config: node.data.config, // the only domain data that matters
  }; // no measured, no flags, no handles
}

Render model vs transport model

The inverse, fromRecord, rehydrates a transport record back into a full render node — recomputing the view state the renderer needs from defaults and layout rules rather than from storage. The principle: anything that can be derived should never be stored. Measured dimensions are derived. Selection is ephemeral. Handle geometry is a function of the node type. Persisting them is persisting a cache. On IntegrateX this also made upgrades safe: renderer changes didn't demand data migrations because we never saved UI-only state.

Zustand as the render store

Keep one store — Zustand is ideal here — as the single owner of the render model. The canvas reads and writes the rich nodes there with zero ceremony. Optimistic updates and cross-node orchestration live here too. Serialization happens only at the boundary: on save, map the store through toRecord; on load, map records through fromRecord back into the store. In my Trinity split, the UI renders from state and dispatches intent; the orchestrator holds the runtime truth; the adapter shapes bytes for the wire. The adapter is the only code that knows both shapes, so the rest of the application never has to.

The 94%, decomposed

The reduction isn't a trick; it's subtraction of baggage. Drop the measured geometry, the per-node interaction flags, the duplicated handle definitions, and the framework metadata; round coordinates to integers. A node that used to serialize to roughly a kilobyte collapses to a few dozen bytes. Across a graph of a hundred nodes, that flips the profile of save, load, and real-time sync from spiky to cheap — fewer bytes on the socket, less state to reconcile, less render churn on rehydrate.

Most payload-size issues aren't compression problems. They're boundary problems — you're shipping the cache because nobody drew the line between the view and the record.

The full pattern, including edge serialization and migration handling, is in the IntegrateX breakdown.