Case study · 2021
LSP Client: an installed IoT network, watched in one place
I built the monitoring client end to end, from the state layer to the live charts and the maps.
Context
Amolexis installs and runs IoT networks for its customers. The people who look after a network need to answer one question fast: is anything wrong, and where. Before this tool, the only way to answer it was to visit devices one at a time and assemble the picture yourself.
The hard part here was not the technology. It was the shape of the work: a freelance engagement, one frontend engineer, and a backend built by the client’s own team on their own schedule. That ruled out anything that needed the API reshaped to suit the interface. The client knew the domain and I did not, so the design had to stay close to how their engineers already described the network. A neater model that only made sense on screen was not an option.
Decisions
- Decision 1
A single store for device state
A single device shows up in the map, in a chart, in a status list, and in whatever panel happens to be open. It is the same record read four ways, and it keeps changing while you watch it. If each widget fetched for itself, the screen could end up showing four slightly different versions of the truth at once. Routing everything through one store instead costs the usual ceremony of actions and selectors—on a project this size, that ceremony is noticeable. What it buys is a screen that stays internally consistent at every moment. For a monitoring tool, that is the whole point.
- Decision 2
Map and charts read from the same selectors
A map tempts you to give it its own data path, because the shape of the data it needs looks different from everything else on screen. I kept it on the same selectors as the rest of the app and reshaped the data at the edge instead. The reshaping code is a little awkward to read. But a device that disappears from the list cannot linger on the map, and the two views can never disagree about what is online.
- Decision 3
Kept the live view honest about what it does not know
A monitoring screen that renders stale data as though it were current is worse than one that admits the gap. The operator stops trusting the tool the first time it lies to them. So state that had not been refreshed showed as unknown. Last known good would have looked tidier, and it would have been dishonest. The interface ends up looking less complete than it could, and that is the right trade.