Context
A High Throughput Screening Reactor lets chemists run many experiments in parallel instead of one after another. Datamole built the software that drives it, and I owned the web application on top.
Scientists use that application to configure the device, schedule experiments and watch them run. An experiment can run for hours, and while it does, the screen is the only window into what is happening inside the hardware. If the interface stutters or lies about the device state, someone loses a day of lab time.
Seven people touched the frontend over four years. Most of it, and most of the decisions in it, were mine: I was the main frontend engineer for nearly three years, and I cut its releases.
The challenge
- Volume. The device streams more than 1,000 data points per second, continuously, for the whole run.
- Responsiveness. Charts have to stay smooth and interactive while that data keeps arriving.
- Hardware reality. The UI has to reflect the true state of a physical machine, including delays, faults and dropped connections, rather than an optimistic guess.
What I built
The experiment scheduler
The centrepiece, and the feature I am most proud of, is a graph editor for experiment schedules. A schedule is a sequence of command nodes, each with its own settings, and the interesting part is the conditions between them: hold until a measurement reaches a target value, hold until it is steady inside a window, wait a repetition interval, block while a coil is in use.
Chemists build those graphs themselves, save them as versioned schedules, clone them, and reuse them across experiments. While an experiment is running, the same editor switches to read-only, because a schedule that changes under a running reactor is a safety problem, not a UX one.
A dashboard the scientist assembles
Rather than one fixed results screen, I built a configurable dashboard: a drag-and-resize grid of widgets that each user arranges for the experiment they are running. Charts, multi-series charts, timelines, photo feeds from the reactor’s cameras, statistics, live values. Each widget is bound to a data group the user defines, with its own filtering, time unit and axis settings, and the layout persists between sessions.
A subscription-based communication layer
I architected the client around subscriptions rather than a single shared stream. Device status, experiment results and immediate command results each negotiate their own SignalR hub connection, and updates land in per-data-group reducer stores instead of one global state tree. A widget re-renders for the series it draws and for nothing else. That one decision is what kept the interface usable as the number of live views grew.
Charts that survived the data rate
The dashboard originally used Vega-Lite, and after a year of fighting it for synchronised, continuously updating charts I migrated the whole dashboard to Chart.js, then built what the data rate actually needed: zoom and pan over hours of history, and data decimation with per-dashboard settings, so a scientist can look at the last thirty seconds or the last three hours without pausing the experiment.
Replacing a charting library across a live product is not a fun quarter. It was the right call, and the dashboard stopped being the thing people complained about.
Everything around the experiment
Device control and channel views, a technician console with multi-switch section control and testing results, device status charts with history, firmware updates with progress and changelogs, camera and photo commands, probe and sample management, measurement settings for conductivity and impedance sweeps, CSV export, label tags with advanced search across experiments and schedules, role management, and a modal system rebuilt on Redux Toolkit so long-running dialogs could be minimised instead of lost.
Integration with the device
The backend is a .NET system with its own workers, sitting between the web application and the reactor. I worked directly with the hardware and backend teams so the web UI and the machine agreed on state, including the unhappy paths: a device that stops answering mid-experiment, a command that is accepted but not yet applied, an experiment that fails during preparation rather than during the run.
Outcome
A reliable, smooth interface for a data-intensive scientific instrument, which I owned, maintained and extended for three years. The architecture outlasted several rounds of new requirements, which is the part I am most pleased about.