realtime applications
Build realtime applications. Not realtime plumbing.
Connect a live feed once and route it across grids, charts, KPIs and operational views. Lattice handles keyed updates, relationships, bursts, reconnects and application state, so your team can concentrate on what the application actually does.
Explore the live demo Data Router documentation →
Vanilla JavaScript. Zero runtime dependencies. Works with React, Vue, Angular, Svelte and your existing stack.
Open the full demo → How the Data Router works → See the starter kits →
the part nobody budgets for
A live feed is easy. A live application isn't.
Opening a WebSocket and printing what arrives is the easy part, and it is usually where the estimate stops. The screen above is what a real operations application actually asks for on top of that one connection: identity for every record, distribution across several views, bursts that arrive faster than a screen should repaint, relationships between what is on screen, coordination so every panel agrees, and a reconnect that picks up where it left off rather than starting the picture over.
What the connection gives you
A socket, and messages. Every device update and every alarm arrives as one more event in the same stream, in whatever order the network delivered them.
What the application needs
A device grid, an alarms grid, a KPI strip and two charts that all agree with each other at every instant, a click on one row that narrows another, and a screen that survives a burst, a quiet spell and a dropped connection without a special case for any of them.
That gap is Lattice Data Router. Point it at one feed, partition it by what each record is, and the grids, charts and KPI tiles above it stay plain views that only know how to show the rows they are handed.
one router, every view
Connect once. Use everywhere.
The demo above is one mixed feed of devices and alarms, and one Data Router in front of it.
createDataRouter partitions that feed by what each record is;
attach points a grid, a chart or a KPI panel at the slice it
should receive. A device record lands in the Devices grid and the KPI strip; an alarm record
lands in the Active Alarms grid and the severity chart. None of the views knows the others
exist, and none of them opened a connection of its own.
The views stay related without staying coupled. router.link ties
the alarms grid to the devices grid on the deviceId they share:
click a device above and the alarms narrow to its own alarms on the spot, no query written by
hand. Badge under the demo names exactly what is running: one feed, two grids, two charts,
four KPIs, one Data Router.
what the router actually handles
Designed for data that doesn't sit still.
Keyed updates
Every device and alarm has an identity. A change lands in place, by that identity, so a grid updates the one row that moved rather than repainting the screen, and scroll, selection, sort and filter all survive the feed running underneath.
Burst handling
A real feed does not arrive at a steady pace. Batch a high-frequency stream or coalesce rapid updates to one key into a single apply, and give a busy route its own backpressure policy so it repaints at a rate the screen can actually show, without slowing any other view.
Relationships
Views are not just fed from the same source, they can be related to each other. A pick in one grid narrows another on a shared field, and a relationship graph carries that through multi-hop chains rather than one pair at a time.
Reconnect and replay
After a dropped socket, resume precisely: load a fresh snapshot as a keyed diff that keeps what every view already has, then replay forward from the last point the router saw, so a reconnect converges on the true state rather than starting the picture over.
Record and replay
Turn on time-travel buffering and the router keeps a bounded, ordered record of the feed. Scrub the whole screen back to a past moment, replay a stretch of an incident at your own pace, and jump back to live in one call, every view moving together.
Observable
The router reports on itself while it runs: how fast each route is actually moving, how far behind it is, and how many records matched nothing, so you can tell the screen is keeping up rather than guessing.
the same architecture, every desk
Built for operational software.
A network operations centre, a trading desk and a logistics wall look nothing alike, but the shape underneath is the same one feed, partitioned, driving several honest, related views. The Data Router does not change between them; only the partition key does.
Trading terminals and desks
Live quotes and the names actually moving are the same market feed seen two ways. See the trading terminal starter kit.
Network operations and observability
Devices and alarms, one feed, related by device id, exactly like the demo running above this page.
Logistics and fleet management
Shipments, vehicles and exceptions on one pipe, driving a grid, a board and a timeline at once. See the logistics operations platform and the fleet telemetry starter kit.
Manufacturing and security operations
Sensor readings and security events both arrive as records that need to be routed, related and kept live in front of the people watching them, not just logged.
Stop building realtime infrastructure. Start building your application.
Development on localhost needs no licence key, so you can wire the router to your own feed and see the real screen move before you decide anything. Licence per domain when you ship.