Every client eventually asks for a dashboard. And every dashboard starts simple — a few charts, a date filter, maybe a table. Six months later, it's the most complex part of the application. Here's how we build dashboards that scale.
Architecture Decisions That Matter Early
The single most impactful decision is where data transformation happens. We push aggregation and filtering to the backend (or database) whenever possible. A React component should receive data shaped for display, not raw datasets that need client-side processing. This keeps bundle sizes manageable and prevents the UI from freezing on large datasets.
State Management for Dashboards
Dashboard state is URL state. Every filter, date range, and view configuration should be reflected in the URL. This gives users shareable links, browser back/forward navigation, and bookmark support for free. We use nuqs (type-safe search params for Next.js) to sync URL state with component state without the boilerplate.
For server state — the actual data powering charts and tables — React Query (TanStack Query) is non-negotiable. Its caching, background refetching, and stale-while-revalidate patterns are exactly what dashboards need. Users see cached data instantly while fresh data loads in the background.
Charting Libraries: Our Stack
After evaluating most options on the market, we've settled on:
- Recharts for standard charts (bar, line, area, pie) — good defaults, responsive, and React-native
- Tremor for pre-built dashboard components when speed matters more than customization
- D3.js directly for highly custom visualizations that no library covers
- TanStack Table for data tables with sorting, filtering, pagination, and virtualization
Real-Time Without the Pain
Most dashboards don't need WebSockets. Polling every 30 seconds with React Query's refetchInterval covers 90% of "real-time" requirements with dramatically less infrastructure complexity. When true real-time is needed (trading dashboards, live monitoring), we use Server-Sent Events over WebSockets — they're simpler, auto-reconnect, and work through proxies without special configuration.
Performance Patterns
Dashboards hit performance walls predictably. Here's how we prevent them:
- Virtualize long lists and tables — render only visible rows
- Debounce filter inputs — don't refetch on every keystroke
- Memoize expensive chart computations with useMemo
- Use Suspense boundaries per widget so one slow query doesn't block the entire page
- Implement skeleton loading states that match the final layout to prevent layout shift
The Template We Start From
Every dashboard project starts with the same skeleton: a sidebar navigation, a header with global filters (date range, entity selector), and a grid layout for widget cards. Each widget is an independent data-fetching unit with its own loading and error states. This isolation means a failing API endpoint degrades one widget, not the entire dashboard.
Dashboards aren't glamorous, but they're where businesses make decisions. Getting the architecture right means those decisions are based on fast, accurate, and reliable data.