UNSFramework
Home/Guides

IMPLEMENTATION CHOICES

Flows and functions: choose a workflow your team can maintain.

Compare a visual flow with the fn-uns component approach, decide what your team needs, and move processing logic only where it helps.

Start with the work, then choose the tool

Use a small, useful example: receive a machine state, store a change, and show a result. Evaluate who can build it, who can support it, and how a change gets tested and deployed.

Node-RED offers visual flows and JavaScript Function nodes. Its Projects feature uses Git for version control. fn-uns packages processing responsibilities as programs in containers. Both need an intentional operating process.

The same question, different packaging

To track machine state, compare a new value with the previous value and store the completed state duration. A flow can express those steps through connected nodes. fn-uns separates MQTT capture, cached values, and state tracking into documented components.

DecisionVisual flowfn-uns components
Where logic livesNodes, node settings, and Function code within a flow.Source files and configuration for each component.
How to reviewReview the flow changes and any embedded code with the team.Review source and configuration diffs with the team.
What to testInputs, transformations, errors, and the full path to the result.Component behavior and shared topic, cache, and database contracts.
What to operateRuntimes, nodes, credentials, state storage, and deployments.Containers, shared infrastructure, credentials, and deployments.

Watch for maintenance friction

Repeated logic, unclear ownership, untested changes, and manual differences between sites can make any implementation hard to maintain. The illustration below describes one possible growth pattern; its node counts are examples, not limits of Node-RED.

PROTOTYPE 5–20 nodes Everything works. Fast, visual, fun. → GROWING 50–100 nodes Flows get complex. Tabs multiply. → STRUGGLING 200+ nodes Nobody understands the full picture. → BREAKING Multi-site Replication is manual & fragile. COMPLEXITY OVER TIME → The inflection point is usually around 50–100 nodes

Before changing tools, look for a simpler structure in the current system. Separate responsibilities, establish shared conventions, and make the release process repeatable.

Define the change process

Keep an identified version of the logic and configuration, review changes, run meaningful checks, then deploy to a known target. Record what is running at each site. Git helps track changes, while the team supplies tests, approval rules, and operational checks.

Plan state persistence explicitly. Node-RED supports filesystem-backed context storage; fn-uns uses a shared cache and database for different responsibilities. Verify the behavior you need after restarts and outages.

A source-code revert does not restore deleted data or undo database changes. Test recovery for the whole system, including its stored state.

Move one responsibility at a time

If a function is a better fit for a particular responsibility, use the existing behavior as its specification. Capture example inputs and expected outputs before moving it.

NODE-RED FLOW → FN-UNS FUNCTION Node-RED Flow State tracking flow — 8 nodes MQTT In Function Switch Compare Duration PostgreSQL Logic: embedded in function nodes Config: node properties dialogs Storage: flows.json (runtime DB) Deploy: click Deploy button → becomes uns-state/ State tracking function — 150 lines Go ├── function.go business logic ├── Dockerfile container def ├── docker-compose.yml service config ├── .env.example env template ├── go.mod dependencies └── README.md documentation Logic: readable Go code in function.go Deploy: git push → auto-build → running
  1. Choose a bounded responsibility, such as state tracking.
  2. Define the inputs, outputs, timing, and error behavior.
  3. Compare the new implementation against the same sample messages.
  4. Use a separate test destination while comparing writes, so two implementations do not duplicate production records.
  5. Switch the consumer after validating the result and the recovery plan.

Find the component for the job

Subscribe and cache →Track state duration →Classify stops →Calculate metrics →Display results →

Measure the workload before expanding

Machine count alone does not tell you how a system will behave. Measure message frequency, payload size, database writes, retention, query load, and recovery time. Adding sites also adds configuration, access, support, and release coordination.

The same component design can be reused across sites, but it still needs capacity testing and operational ownership at each deployment.

Choose based on evidence from the pilot

Keep a flow where it is understandable and well supported. Use functions where their packaging and review process fit the team. A mixed system can be a deliberate choice: both can exchange messages through the shared namespace.

1. EXPERIMENT Node-RED Prove the concept → 2. VALIDATE Node-RED + fn-uns Run both in parallel → 3. PRODUCTION fn-uns + GitOps Scale with confidence → 4. SCALE Multi-site git push to deploy Each step builds on the previous — your Node-RED prototype becomes the spec for your production functions

The diagram illustrates a possible migration path. Moving from flows to functions is optional; evaluate it against your team’s needs rather than treating it as a required maturity step.

All guides →fn-uns design choices →Try the sample pipeline →