Back to portfolio
Case Study

PulseOps

Real-time Operations Monitoring Dashboard

A real-time React monitoring application demonstrating advanced server-state management, WebSocket synchronization, virtualization, optimistic updates and browser-level testing.

ReactTypeScriptTanStack QueryWebSocketsReact RouterTanStack VirtualRechartsVitestPlaywright
PulseOps application screenshot
The Problem

What this project demonstrates

PulseOps explores how a React application can process a continuous stream of operational data while keeping the UI responsive and the data model predictable. The main challenge is combining an initial REST snapshot with high-frequency WebSocket events without creating two competing sources of frontend state.

Architecture

System architecture

01
REST APITanStack Query cache

Loads the initial monitoring snapshot.

02
WebSocketTanStack Query cache

Incoming realtime events update the existing snapshot with queryClient.setQueryData().

03
TanStack Query cacheSelector-based consumers

Components subscribe only to the data slices they need.

04
Query consumersReact UI

KPIs, charts, services and request streams render from the same server-state source.

REST and WebSocket data are deliberately unified inside the TanStack Query cache. WebSocket events do not create a second client-side state store. Instead, each validated event immutably updates the existing monitoring snapshot, keeping the React UI synchronized around one source of server state.

Engineering Decisions

Key decisions

One cache for REST and realtime data

The initial snapshot arrives through REST, while WebSocket messages call queryClient.setQueryData() against the same query key. This avoids maintaining parallel realtime state and reduces synchronization problems.

Selector-based render isolation

Overview components subscribe to focused slices such as KPIs, services or requests. A new request event therefore does not need to re-render every dashboard panel.

Bounded high-frequency buffers

The realtime reducer keeps request history bounded to 5,000 events and chart history bounded separately. This prevents an endlessly growing in-memory stream.

URL as durable UI state

Dashboard environment, time range and request explorer filters are synchronized with URL search parameters. Views can be refreshed, shared and navigated with normal browser history.

Targeted optimistic rollback

Incident updates optimistically modify only the selected incident. If the request fails, only that incident is restored instead of replacing the entire monitoring snapshot and potentially discarding newer WebSocket events.

Performance

Performance approach

Virtualized request stream

TanStack Virtual renders only the visible portion of the request explorer while the application can retain up to 5,000 request events.

Render isolation

Stable selectors and focused query subscriptions prevent unrelated realtime events from propagating through the whole overview component tree.

Bounded data structures

Realtime arrays have explicit maximum sizes so a long-running dashboard does not continuously accumulate request or chart data.

Testing

Testing strategy

Vitest

Unit coverage for realtime reducer behavior, query updates, filters and optimistic rollback logic.

React Testing Library

Component-level tests for monitoring behavior and render isolation.

Playwright

Browser-level coverage for navigation, URL filters, virtualization, mobile behavior and optimistic incident updates.

GitHub Actions

CI runs linting, TypeScript checks, unit tests, production builds and Playwright E2E validation.

Product

Application screens

PulseOps realtime operations dashboard
Overview dashboard with realtime KPIs and service health.
PulseOps virtualized request explorer
Virtualized request stream with URL-synchronized filtering.
PulseOps incidents monitoring page
Incidents and realtime operational metrics.
PulseOps traffic monitoring page
Traffic inspection page.
Trade-offs

Challenges & trade-offs

  • 01The monitoring backend is a deterministic simulator rather than a production observability platform. The project is focused on frontend architecture and realtime behavior.
  • 02The selected time range and environment are URL-backed interface state but do not currently represent a historical backend query engine.
  • 03Keeping 5,000 request events in memory is appropriate for this demonstration, but a larger production system could use server-side pagination or persistent event storage.
  • 04Direct cache updates require well-defined realtime event contracts because malformed payloads can otherwise corrupt shared server state.