[{"data":1,"prerenderedAt":204},["ShallowReactive",2],{"application-guide-nav":3,"application-guide-node-red-worked-example":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":76,"blocks":103,"blurb":77,"extension":200,"guide":12,"meta":201,"navOrder":71,"slug":75,"stem":202,"__hash__":203},"applicationGuide\u002Fapplication-guide\u002Fnode-red\u002F07-worked-example.yml",[104,108,196],{"type":105,"kicker":106,"body":107},"prose","Worked example — start here","The shape rules and patterns applied end to end. One app reached three ways over shared services, and the same requirement built with and without seams — so you can see what the seams buy you.",{"type":109,"panels":110},"tabs",[111,163],{"label":112,"kicker":113,"kickerNote":114,"diagramTitle":115,"diagram":116,"lists":155},"Napkin: multi-surface app","One app, three surfaces","An HTTP API, a dashboard and MQTT over one shared Tables pool; each surface ends at its own sink.","Node-RED · Data-Driven App — three surfaces, one shared pool",{"lanes":117,"legend":151,"note":154},[118,131,133,140,142],{"label":119,"tone":120,"nodes":121},"Surfaces · each beginning its own path","neutral",[122,125,128],{"title":123,"sub":124},"MQTT in","devices",{"title":126,"sub":127},"http in","services",{"title":129,"sub":130},"dashboard","people · reuses HTTP",{"link":132},"link call",{"label":134,"tone":135,"nodes":136},"Shared services","it",[137],{"title":138,"sub":139,"tone":135},"Tables pool","one pool · link call",{"link":141},"results return",{"label":143,"tone":120,"nodes":144},"Sinks · one per surface",[145,148],{"title":146,"sub":147},"MQTT out","publish",{"title":149,"sub":150},"http res","respond",[152],{"label":153,"tone":135},"call \u002F return","One app reached three ways over shared services.",[156],{"heading":157,"items":158},"The pieces",[159,160,161,162],"Surfaces — a dashboard for people, an HTTP API for services, an MQTT feed for devices and events. Each beginning is its own path, so a device path never runs through a browser path.","Shared services — one Tables pool and one external service call, both invoked with link call. One pool serves all three surfaces without mixing them.","Single sink — each surface converges on one sink through a labeled link, an http response or an MQTT publish. It only sends; the HTTP path responds exactly once, the MQTT path just publishes.","People reuse HTTP — the dashboard is a ui-template that fetches the HTTP API, so it adds no new backend paths of its own.",{"label":164,"kicker":165,"kickerNote":166,"diagramTitle":167,"diagram":168,"lists":189},"Good vs bad","Same requirement, with vs without seams","Draw the boundary on purpose and define the contract; spaghetti has nowhere to accumulate.","One tab, everything — versus four named tabs",{"lanes":169,"note":188},[170,177],{"label":171,"tone":172,"nodes":173},"One tab, everything","ot",[174],{"title":175,"sub":176,"tone":172},"Node-RED","one flow, everything tangled",{"label":178,"tone":135,"nodes":179},"Four named tabs",[180,182,184,186],{"title":181,"tone":135},"Config",{"title":183,"tone":135},"Ingestion",{"title":185,"tone":135},"Processing",{"title":187,"tone":135},"Presentation","The same requirement built with and without seams.",[190],{"heading":157,"items":191},[192,193,195],"The bad version — one tab, everything on it. Tags and thresholds frozen in Function nodes, a template that holds logic and pulls its own data, the full object threaded node to node. A second line means copy, paste, edit.",{"The good version — four tabs with clear boundaries":194},"Config, Ingestion, Processing, Presentation. Config lives in a persistent store the operator edits, the template only renders a view-model, and state lives in a namespaced context key.","Why it wins — named seams you can read one at a time, runtime config with no redeploy, a clean UI boundary, and a Threshold Evaluator subflow, so a second line is configuration rather than copy-paste.",{"type":197,"heading":198,"body":199},"sentence","The architecture, in one sentence","A Software: Data-Driven App backed by a Relational DB, reached three ways over one shared Tables pool and one external service call, each surface ending at its own sink. Draw the boundary on purpose and define the contract across it, and there is nowhere for spaghetti to accumulate.","yml",{},"application-guide\u002Fnode-red\u002F07-worked-example","MwXlPX9654rfFSPBafvPDMuqduvvVUpHS1pXQZN4uuU",1786132521812]