FlowFuse Application Guide

Two guides for the decisions you make before you start building: which FlowFuse pieces an app is made of, where they run, and what a flow should look like once it is. This is the material we walk through during a proof of concept, written down so you can work through it yourself.

FlowFuse Guide

Turn an app idea into FlowFuse pieces you can name and say in one sentence.

  • Overview — The map of the FlowFuse guide — apps, architectures, and a worked example.
  • Foundations — The foundation to build on: what FlowFuse is, its core pieces, and how code is shared across teams.
  • App delivery methods — Two different units of code, delivered two ways. Ship the whole app — a complete, versioned project promoted through environments — or publish one reusable piece — a package the whole team installs and upgrades in one place. Pick by what you're shipping: the app, or a part of it.
  • Hardware apps — The three shapes a FlowFuse app takes when it runs on a device. Pick by how much varies per site: nothing (Packaged App), a few settings (Configurable App), or you assemble it yourself (Edge Building Block).
  • Software apps — The three shapes a FlowFuse app takes when it runs on the platform. Pick by what it needs: a headless job (Packaged App), a user-facing app driven by data (Data-Driven App), or a reusable piece other apps embed (Shared Building Block).
  • Data plane — Before you pick where things run, decide how data is handled. Two stores come built into every FlowFuse server install — the Team Broker and relational Tables — exposed to every instance with nothing extra to stand up. Everything else you bring your own: run it (a time-series DB, an existing database, a model) and expose it to the fleet over Project Link, no inbound ports. This is the data plane the architectures on the next pages all sit on.
  • Architectures — Every FlowFuse deployment is the same building blocks arranged for where it runs — pick the world you're designing for.
  • IT architectures
  • OT architectures
  • IIoT architectures
  • Worked examples — Start from a use case, break it into apps, and draw the architecture that ties them together — the same method a FlowFuse Proof of Value runs.
  • OEE, end to end — One use case — OEE across three lines — broken into two apps and two shared services, then drawn out end to end.

Node-RED Guide

Turn an architecture sentence into a clean flow shape you can read at a glance.

  • Overview — The map of the Node-RED guide — the pattern families that turn an app into a clean flow.
  • Foundations — The handful of concepts you need to build with Node-RED, and how they fit together.
  • Patterns — The moves that turn an architecture into a clean, reusable flow — find the seams and reuse well, then handle data on the right paths.
  • Design patterns — The structural choices you select for a flow: find the seams it breaks into, then reuse each piece at the lightest level that solves it — link in/out, link call, subflow, or packaged node.
  • Handling data — Classify each signal by shape, purpose and direction, then pick the methods it needs — separate the paths, pace the flow, hold state in context, and manage config. The methods you select to move a flow's data.
  • Good form — A clean flow isn't luck — it's a handful of habits. Wire for reading, lay it out on a grid, decouple UI from logic, catch errors where you can see them, and keep data on a stable contract. Follow these and a flow stays readable, reusable, and out of spaghetti.
  • Worked examples — Turn an app concept into a Node-RED flow — or a few — leaning on the design patterns and data handling. The method, then the OEE apps end to end.
  • OEE - Edge Aggregator — The edge app from the OEE use case as a Node-RED flow — a straight-line flow packaged as a subflow and configured per line (its PLC tags, via a config UI and a get-config node), with the data treated as a stream and its counts held in context.
  • OEE - Central Dashboard — The cloud app from the OEE use case as a Node-RED flow — one link out fanning to two link ins on separate tabs (dashboard and batched history), so the live and history paths stay separate and easy to read.