[{"data":1,"prerenderedAt":264},["ShallowReactive",2],{"application-guide-nav":3,"application-guide-node-red-operating-flows":101},[4,11,15,21,24,30,35,41,46,52,57,63,68,74,79,85,91,97],{"guide":5,"slug":6,"title":7,"navOrder":8,"blurb":9,"path":10},"flowfuse","overview","Overview",1,"Turn an app idea into FlowFuse pieces you can name and say in one sentence.","\u002Fapplication-guide\u002Fflowfuse\u002Foverview\u002F",{"guide":12,"slug":6,"title":7,"navOrder":8,"blurb":13,"path":14},"node-red","Turn an architecture sentence into a clean flow shape you can read at a glance.","\u002Fapplication-guide\u002Fnode-red\u002Foverview\u002F",{"guide":5,"slug":16,"title":17,"navOrder":18,"blurb":19,"path":20},"foundations","Foundations",2,"The foundation to build on: what FlowFuse is, its core pieces, and how code is shared across teams.","\u002Fapplication-guide\u002Fflowfuse\u002Ffoundations\u002F",{"guide":12,"slug":16,"title":17,"navOrder":18,"blurb":22,"path":23},"The handful of concepts you need to build with Node-RED, and how they fit together.","\u002Fapplication-guide\u002Fnode-red\u002Ffoundations\u002F",{"guide":5,"slug":25,"title":26,"navOrder":27,"blurb":28,"path":29},"app-delivery-methods","App delivery methods",3,"Two different units of code, delivered two ways: ship the whole app, or publish one reusable piece.","\u002Fapplication-guide\u002Fflowfuse\u002Fapp-delivery-methods\u002F",{"guide":12,"slug":31,"title":32,"navOrder":27,"blurb":33,"path":34},"flow-shape","Flow shape","Turn an architecture sentence into a flow you can read at a glance.","\u002Fapplication-guide\u002Fnode-red\u002Fflow-shape\u002F",{"guide":5,"slug":36,"title":37,"navOrder":38,"blurb":39,"path":40},"hardware-apps","Hardware apps",4,"The three shapes a FlowFuse app takes when it runs on a device.","\u002Fapplication-guide\u002Fflowfuse\u002Fhardware-apps\u002F",{"guide":12,"slug":42,"title":43,"navOrder":38,"blurb":44,"path":45},"design-patterns","Design patterns","The moves that turn a flow into something you can reuse, test and hand off.","\u002Fapplication-guide\u002Fnode-red\u002Fdesign-patterns\u002F",{"guide":5,"slug":47,"title":48,"navOrder":49,"blurb":50,"path":51},"software-apps","Software apps",5,"The three shapes a FlowFuse app takes when it runs on the platform.","\u002Fapplication-guide\u002Fflowfuse\u002Fsoftware-apps\u002F",{"guide":12,"slug":53,"title":54,"navOrder":49,"blurb":55,"path":56},"handling-data","Handling data","Sort data by what it is for before you tune anything.","\u002Fapplication-guide\u002Fnode-red\u002Fhandling-data\u002F",{"guide":5,"slug":58,"title":59,"navOrder":60,"blurb":61,"path":62},"data-plane","Data plane",6,"Before you pick where things run, decide how data is handled.","\u002Fapplication-guide\u002Fflowfuse\u002Fdata-plane\u002F",{"guide":12,"slug":64,"title":65,"navOrder":60,"blurb":66,"path":67},"operating-flows","Operating flows","Four operational habits that keep a flow running when the real world pushes back.","\u002Fapplication-guide\u002Fnode-red\u002Foperating-flows\u002F",{"guide":5,"slug":69,"title":70,"navOrder":71,"blurb":72,"path":73},"architectures","Architectures",7,"The same building blocks, arranged for where they run.","\u002Fapplication-guide\u002Fflowfuse\u002Farchitectures\u002F",{"guide":12,"slug":75,"title":76,"navOrder":71,"blurb":77,"path":78},"worked-example","Worked example","The shape rules and patterns applied end to end.","\u002Fapplication-guide\u002Fnode-red\u002Fworked-example\u002F",{"guide":5,"slug":80,"title":81,"navOrder":82,"blurb":83,"path":84},"it-architectures","IT architectures",8,"Hosting the platform and serving the wider organisation.","\u002Fapplication-guide\u002Fflowfuse\u002Fit-architectures\u002F",{"guide":5,"slug":86,"title":87,"navOrder":88,"blurb":89,"path":90},"ot-architectures","OT architectures",9,"How FlowFuse deploys in operational-technology environments, near the equipment.","\u002Fapplication-guide\u002Fflowfuse\u002Fot-architectures\u002F",{"guide":5,"slug":92,"title":93,"navOrder":94,"blurb":95,"path":96},"iiot-architectures","IIoT architectures",10,"Distributed edge nodes, each doing one small job, feeding one central system.","\u002Fapplication-guide\u002Fflowfuse\u002Fiiot-architectures\u002F",{"guide":5,"slug":75,"title":76,"navOrder":98,"blurb":99,"path":100},11,"OEE, end to end — two packages, two connections.","\u002Fapplication-guide\u002Fflowfuse\u002Fworked-example\u002F",{"id":102,"title":65,"blocks":103,"blurb":66,"extension":260,"guide":12,"meta":261,"navOrder":60,"slug":64,"stem":262,"__hash__":263},"applicationGuide\u002Fapplication-guide\u002Fnode-red\u002F06-operating-flows.yml",[104,108],{"type":105,"kicker":106,"body":107},"prose","Operating flows — start here","A clean flow shape isn't enough to survive production. Four operational habits keep a flow running when the real world pushes back: catch errors on a path you control, pace fast inputs so memory doesn't blow, deploy with the smallest restart, and keep the flow observable.",{"type":109,"panels":110},"tabs",[111,155,192,227],{"label":112,"kicker":113,"kickerNote":114,"diagramTitle":115,"diagram":116,"summary":148,"useWhen":149,"howHeading":150,"how":151,"callout":152},"Error handling","Design the error path","A Catch node per tab turns a thrown error into a route you control, not a silent stall.","Node-RED runtime · one error path per tab",{"lanes":117,"legend":143},[118,131,133],{"label":119,"tone":120,"nodes":121},"Happy path","neutral",[122,125,128],{"title":123,"sub":124},"in","msg enters",{"title":126,"sub":127},"work","may throw",{"title":129,"sub":130},"sink","on success",{"link":132},"throws",{"label":134,"tone":135,"nodes":136},"The error path","ot",[137,140],{"title":138,"sub":139,"tone":135},"Catch","scoped to this tab",{"title":141,"sub":142,"tone":135},"log · notify · retry","the error path",[144,146],{"label":145,"tone":120},"success",{"label":147,"tone":135},"error (Catch)","Every flow that talks to the outside world will fail sometimes — a DB is down, a payload is malformed, a request times out. Node-RED routes those failures to a Catch node instead of crashing; you decide what happens next.","Any flow with I\u002FO: HTTP calls, DB writes, broker publishes, file access — i.e. almost all of them.","How to do it","Drop a Catch node on the tab (scope it to specific nodes or the whole tab). Throw with node.error(msg, msg) so the message reaches Catch. From Catch, branch to log, notify, or retry — and on an API flow, respond with an error status instead of hanging. Pair with a Status node to surface node health on the canvas.",{"tone":153,"text":154},"watch","An unscoped tab-wide Catch that re-runs your success\u002Fresponse nodes will double-respond; keep the error path separate from the happy path.",{"label":156,"kicker":157,"kickerNote":158,"diagramTitle":159,"diagram":160,"summary":187,"useWhen":188,"howHeading":150,"how":189,"callout":190},"Backpressure & memory","Pace the fast side to the slow side","When input outruns a sink, the queue grows and the heap blows. This is the","Node-RED runtime",{"lanes":161,"note":186},[162,168,170,177,179],{"label":163,"tone":120,"nodes":164},"Fast in · many msg\u002Fs",[165],{"title":166,"sub":167},"MQTT in","fast · bursty",{"link":169},"many msg\u002Fs",{"label":171,"tone":172,"nodes":173},"The brake","it",[174],{"title":175,"sub":176,"tone":172},"rate limit \u002F batch","delay · queue · drop",{"link":178},"steady rate",{"label":180,"tone":120,"nodes":181},"Slow side",[182],{"title":183,"sub":184,"tone":185},"DB write","slow · the bottleneck","muted","No pacing here → the queue grows and the heap blows.","A fast source (an MQTT topic, a tight poll) feeding a slow sink (a DB write, an API) has no natural brake. Messages pile up in memory faster than they drain, and the runtime eventually runs out of heap and dies.","Any high-rate or bursty input into a slower downstream — telemetry to a database, fan-out to a remote API.","Pace the slow side explicitly: a delay node in rate-limit mode, batching (join into chunks), or dropping stale readings when only the latest matters. Batched inserts also cut per-write overhead. Watch heap and the node's queue; if it only grows, you have backpressure, not a spike.",{"tone":153,"text":191},"A backend that holds a live connection (an MQTT subscription) can't be pooled away; pace at the source or offload the heavy work.",{"label":193,"kicker":194,"kickerNote":195,"diagram":196,"summary":222,"useWhen":223,"howHeading":150,"how":224,"callout":225},"Deploy modes","Pick the smallest restart that ships the change","Full vs Modified Flows vs Modified Nodes decide what stops and what keeps running.",{"lanes":197},[198,207,215],{"label":199,"tone":135,"nodes":200},"Full — restarts the whole runtime (all tabs, all connections drop)",[201,203,205],{"title":202,"tone":135},"tab A",{"title":204,"tone":135},"tab B",{"title":206,"tone":135},"connections",{"label":208,"tone":209,"nodes":210},"Modified Flows — restarts only tabs you changed","dmz",[211,213],{"title":212},"changed tab",{"title":214,"tone":185},"unchanged tabs keep running",{"label":216,"tone":172,"nodes":217},"Modified Nodes — restarts only the nodes you changed (default; least disruptive)",[218,220],{"title":219,"tone":172},"changed node",{"title":221,"tone":185},"open connections survive","Deploy doesn't just save — it restarts nodes, and that drops their connections and in-flight state. Node-RED offers three scopes so you don't restart the world for a one-node change.","Every deploy to a running system, especially one holding live connections (brokers, serial, websockets) you don't want to bounce.","Modified Nodes (the default) restarts only nodes you edited — least disruptive. Modified Flows restarts changed tabs. Full restarts everything and drops all connections. Prefer the smallest scope; use Full when config nodes or global state changed. Deploying via the Admin API (POST \u002Fflows) takes a Node-RED-Deployment-Type header that sets the same modes.",{"tone":153,"text":226},"Nodes holding a connection re-initialise on restart; a Full deploy on a busy broker flow drops and re-subscribes everything.",{"label":228,"kicker":229,"kickerNote":230,"diagramTitle":159,"diagram":231,"summary":254,"useWhen":255,"howHeading":150,"how":256,"callout":257},"Debugging","Make the flow observable","Tap the wire, surface node state, and keep enough on the message to trace it.",{"lanes":232,"legend":249},[233,241,243],{"label":234,"tone":120,"nodes":235},"The flow",[236,237,240],{"title":123},{"title":238,"sub":239},"function","node.status()",{"title":129},{"link":242},"inspect msg",{"label":244,"tone":172,"nodes":245},"Debug tap",[246],{"title":247,"sub":248,"tone":172},"debug","tap the wire",[250,252],{"label":251,"tone":120},"flow",{"label":253,"tone":172},"debug tap","You can't fix what you can't see. Node-RED gives you live message inspection and per-node status without stopping the flow — use them instead of guessing.","Building, and any time a flow misbehaves in a way the shape doesn't explain.","Drop a debug node to tap any wire (view msg.payload or the full msg, and route to the sidebar). Call node.status() \u002F node.warn() to surface state and hints on the canvas. Keep enough context on the message to trace a request end-to-end — but don't ship fat debug payloads to production dashboards.",{"tone":258,"text":259},"good","Confirming which branch a message took and what it carried, before assuming the logic is wrong.","yml",{},"application-guide\u002Fnode-red\u002F06-operating-flows","b9-7YGTB7rM69vtq2oKxXQaZ6mXw_I_PNMGCdAELk0U",1786132521792]