A customer dashboard in Next.js
We rebuilt the dashboard customers use in Next.js, a widely used framework for web apps. It draws the device state the server has settled.
IoT dashboard case study: smart home
A smart home provider's dashboard couldn't keep up with its own device data, so customers were looking at device state (what each device is doing) that was already out of date. We rebuilt it as a Next.js web app fed by a streaming pipeline, which passes on each device event as it arrives. It serves more than 8,000 connected homes.
The challenge
In a connected home, a screen that shows old device state is a screen that disagrees with the house.
Devices in connected homes rarely send tidy data. Four things made it hard here:
It looked like a performance problem in the front end, the part that runs in the browser, and partly it was. But speeding up the page on its own would only have shown the wrong state sooner.
The real question was which reading counts as current when events arrive late, out of order or twice. That decision belongs on the server, where every event can be seen, not in each customer's browser.
What we built
The rebuild moved the decision about what is current off the browser and onto the server. The browser shows the server's answer.
We rebuilt the dashboard customers use in Next.js, a widely used framework for web apps. It draws the device state the server has settled.
A streaming pipeline carries device events to the dashboard. Streaming means each event is passed on as it arrives, one after another, rather than collected up and sent later.
The server reconciles device state: it sees every event, including late and repeated ones, and decides which reading is current. The browser is never the thing deciding.
The impact
Customers see device state in real time, settled on the server rather than guessed at in the browser. The figures are the client's own, as reported to us.
What made it work
Engineers call this idempotency: handling an event twice gives the same result as handling it once.
Devices drop off, clocks drift and the same event turns up twice. If processing an event twice changes the result, the dashboard is wrong in a way no front-end work can fix.
So most of the effort went into idempotent event handling: making every event safe to receive more than once, so an event that arrives twice changes nothing the second time. Nobody sees that work on the screen. It is the reason the screen can be believed.
Related work
The service behind this project, and other projects we have written up.
See every case study, or browse all our services.
Let's talk
Tell us how events reach it. The fix is usually further upstream than the page. We reply within one working day.