Operations teams want to see what is happening now: new orders, shipments in transit, machines running, tickets waiting. A dashboard that needs a manual refresh feels old, and a dashboard that hammers the server with every possible query feels worse. Our standard stack for business applications is Laravel with Inertia.js and React, used in projects such as the Earth Movers ERP and the Narmar Express Shipping Platform. This article compares the practical ways to make dashboards feel live in that stack, and when each one fits.
"Real time" is a spectrum, and the right choice depends on what the viewer does with the information. Ask three questions for each widget on the page.
- How quickly does a change matter: within a second, a minute, or an hour?
- How often does the data actually change?
- How many people watch it at the same time?
A count of orders waiting for dispatch may need to be fresh within seconds. A monthly revenue chart can update every few minutes without anybody noticing. Mixing the two on one screen is normal, and each widget can use a different technique.
Technique 1: partial reloads
Inertia lets a page request only some of its props instead of the whole page. On the server you return a closure for expensive data, and on the client you reload just the pieces that changed.
router.reload({ only: ['stats', 'recentOrders'] });This keeps the page state, scroll position and form inputs intact, and avoids recomputing everything else. Partial reloads are the foundation for the other techniques, because they let you refresh one panel without touching the rest.
Load heavy panels after the page appears
Deferred props let the page render immediately with placeholders, then load slow queries in a follow-up request. Show a skeleton, not a blank space, so users understand something is loading. This is especially useful for dashboards with several slow reports, because the first screen appears fast on modest connections.
Technique 2: polling
Polling asks the server for fresh data on a timer. Inertia provides a polling helper that reloads chosen props at an interval and pauses when the tab is hidden, which saves resources.
usePoll(15000, { only: ['stats'] });When polling is the right answer
- Updates every 10 to 60 seconds are good enough.
- You have a modest number of simultaneous viewers.
- You want the simplest possible implementation with no extra infrastructure.
Keep polling cheap
Each poll should hit a light query. Cache aggregated numbers for a few seconds, add database indexes for the filters you use, and return only the props that changed. A dashboard that runs twenty heavy queries every ten seconds for fifty people will become your slowest page. Use longer intervals for widgets that rarely change, and stop polling when nobody is looking.
Technique 3: broadcasting with WebSockets
When updates must appear within a second, or when many events arrive unpredictably, push beats poll. Laravel's broadcasting system sends events from the server to the browser over WebSockets, using a server such as Laravel Reverb or a hosted service. In the browser, Laravel Echo subscribes to a channel, and your React component reacts to each event.
A sensible pattern
Keep the event small: broadcast the fact that something changed, and let the client reload only the relevant props through Inertia. This gives you real-time triggers while keeping all formatting, permissions and calculations on the server, instead of duplicating them in the browser.
Echo.private('dispatch.' + branchId)
.listen('ShipmentUpdated', () => {
router.reload({ only: ['shipments'] });
});What you take on
WebSockets add a long-running server to operate, secure and monitor. Private channels need authorization so users only receive events for data they may see, which matters greatly in multi-tenant systems. Plan for reconnection, because mobile and office networks drop connections, and always refresh the data on reconnect so nobody is left looking at stale numbers.
Design the dashboard so the data stays trustworthy
Show when data was last updated
A small timestamp builds trust and exposes problems. If a connection fails, tell the user rather than silently displaying old figures.
Avoid layout jumps
Reserve space for numbers and lists so content does not shift as updates arrive. Highlight changes briefly rather than animating everything, and let users pause live updates when they are reading or comparing rows.
Respect permissions and tenants
Every query behind a widget must be scoped to what the user is allowed to see. Test it with feature tests that fetch the dashboard as different users and assert on the returned props.
Handle large lists and charts
Paginate or limit lists, aggregate in the database instead of in JavaScript, and downsample long time series before they reach the chart. The browser should render summaries, not raw tables of thousands of rows.
Which technique should you choose?
| Need | Good fit |
|---|---|
| Refresh one panel after a user action | Partial reload |
| Slow reports on first load | Deferred props with skeletons |
| Fresh within a minute, few viewers | Polling |
| Fresh within seconds, many events | Broadcasting with partial reloads |
Start with partial reloads and polling. They are simple, robust and enough for most business dashboards. Add broadcasting for the few screens where seconds matter, such as a dispatch board or a live order queue.
If you need dashboards that your operations team will actually use, the Narmar team can design and build them with you. See our projects, browse our services, or contact us to talk about your data.
