Generated page. Written from IdaMilk/Statado_Backend at commit 65df0d2 on 2026-07-28, version 1.0.0. No README; inferred from source.
Statado Backend
What is it?
The Express service behind Statado. Its package.json describes it as the "andon / live manufacturing reporting service".
It owns help requests, the departments and devices they route between, and the Socket.IO broadcast that keeps every board in sync.
Purpose
When an operator raises a help request, three things must happen: it must be recorded, it must reach the right department, and every board must show it immediately. This service does all three.
The recording half matters as much as the alerting half — a call log of what stopped the line, how often, and how long it took to resolve is the raw material for actually fixing recurring problems.
How it Works
Express with Sequelize over SQL Server, plus Socket.IO for live push.
A device raises a help request against a reason. The service persists it, resolves which department should respond — devices carry watchedDepartmentIds, added in migration 004 — and broadcasts the event so every connected board updates. On resolution, a resolutionNote is captured (migration 002), turning the log from "this happened" into "this happened and here is why".
Devices can carry questions: a configurable set of prompts with predefined options, presented when a request is raised, so the responding department arrives with context rather than just a summons.
Data model
All models are SP-prefixed.
| Model | Holds |
|---|---|
SPHelpRequest | Individual help requests and their resolution |
SPHelpReason | Configurable reasons a request can be raised |
SPHelpRequestAnswer | Answers to device questions on a request |
SPDevice | Registered plant-floor devices, line position, watched departments |
SPDeviceQuestion / SPDeviceQuestionOption | Per-device prompts and their options |
SPDepartment | Responding departments |
SPGroup | Grouping |
Migrations
Unusually for this codebase, schema changes are numbered migration files rather than a boot-time ensureRuntimeSchema() call:
| Migration | Change |
|---|---|
001 | linePosition on devices |
002 | resolutionNote on help requests |
003 | Settings table |
004 | watchedDepartmentIds on devices |
This is the more conventional and more auditable approach — the migration list doubles as a readable history of how the model evolved.
Tech Stack
| Technology | Version | Purpose |
|---|---|---|
| Express | 5.2.1 | HTTP framework |
| socket.io | 4.8.3 | Live event broadcast |
| Sequelize | 6.37.7 | ORM |
| tedious | 19.2.1 | SQL Server driver |
| morgan | 1.10.1 | Request logging |
| body-parser | 1.20.3 | Request parsing |
| cors | 2.8.6 | Cross-origin support |
| dotenv | 17.3.1 | Configuration |
Interfaces
| System | Direction | Purpose |
|---|---|---|
| Statado | both | REST plus Socket.IO |
| Plant-floor devices | inbound | Help request submission |
| SQL Server | outbound | All persistence |
Note this service runs its own Socket.IO server rather than routing broadcasts through the SunApps Gateway as the manufacturing services do. Andon is architecturally independent of the SunApps platform.
Operations
A single deploy.yml workflow. Configuration is .env via config/index.js — port and SQL Server connection.
Migrations are files, so applying them is a deliberate step; confirm they have run after a deploy rather than assuming the schema self-heals.
Repository
| Repository | IdaMilk/Statado_Backend |
| Version | 1.0.0 |
| Primary language | JavaScript (Node, CommonJS) |
| Files | 28 |
| Last activity | 2026-05-04 |
| Status | Active |
| README | None |