.jpg)
Real-time systems usually accumulate infrastructure. One service handles device messaging, another manages browser connections, a third exposes APIs, and additional layers keep state consistent between them. Each component solves a specific problem, but the system only works once everything is stitched together.
The demo in this video takes a different approach. It shows what real-time pub/sub looks like when storage, messaging, and protocol handling live in the same runtime.
State as the System Boundary
The LED sign in the demo is backed by a single table that represents its current state. That table isn’t just a persistence layer. It is also what directs all real-time behavior.
When a value in the table changes, Harper publishes an event. When a client subscribes, it listens for changes to that same table. Whether the change originates from a device, a browser, or an API call doesn’t matter—the runtime treats all updates the same.
This shifts the design focus from integrating services to modeling state transitions.
Protocols Without Translation Layers
Different clients interact with the table using different protocols. Devices publish updates over MQTT. Browser-based views subscribe via Server-Sent Events or WebSockets. UI controls update state through REST.
Because Harper natively supports these protocols, there is no translation layer converting messages between systems and no secondary source of truth to reconcile. Each protocol is simply another way to read from or write to the same data model.
Interoperability emerges naturally from this design rather than being configured explicitly.
Why This Simplifies Architecture
In most real-time architectures, messaging systems and databases evolve independently. Messages describe events, while databases describe state, and significant effort goes into keeping the two aligned.
In Harper, pub/sub is tied directly to data changes. The table becomes both the system of record and the event source. That removes entire classes of synchronization problems and eliminates the need for external brokers or coordination services.
The result is a system that behaves like a unified whole rather than a collection of integrated parts.
Making the Model Concrete
The MQTT Getting Started repository used in the demo exists to illustrate this pattern in practice. It shows how a single table can support publishing and subscribing across MQTT, WebSockets, Server-Sent Events, and REST without additional infrastructure.
You don’t need to study the implementation details to apply the idea. The important takeaway is architectural: real-time behavior is attached to data itself, not to a specific transport or service.
A Different Way to Think About Real-Time Systems
This approach changes how real-time applications are designed. Instead of planning message flows and protocol boundaries, you define shared state and let the runtime handle distribution.
That’s why the system in the video looks deceptively simple. The complexity hasn’t been hidden—it’s been removed by collapsing multiple responsibilities into a single platform.
For teams building real-time applications, that shift can make the difference between managing a stack and building on a system.
.webp)
%20(1).png){kind=icon}
.png){kind=icon}
.png){kind=icon}