The Cardinal application

The front end.

For: developers

Cardinal's front end is a React single-page application: typed end-to-end, server-state cached, and built for fast, scannable reading of engagement data. It talks to the back end over a typed API and is hosted as a static site on Azure.

React SPA Typed API client Static Web Apps

🧱 The stack 🧭 Routing & data 🔑 Auth in the client

The stack

Concern	Choice
UI framework	React 18
Routing	TanStack Router (file-based)
Server state	TanStack Query (caching, invalidation)
API client	tRPC typed client — types shared with the back end
Charts	ECharts for metrics and cost
Markdown	React Markdown with sanitisation
Build	Vite
Large lists	Virtualised rendering for big tables

Typed end to end. Because the API client and the server share their type definitions, a change to a procedure's shape surfaces as a compile error in the front end — not as a runtime surprise. The shared types live in a workspace package consumed by both halves.

Routing & data flow

File-based routing

Each page is a route file; the URL structure mirrors the engagement's page map. Navigation is client-side, with data fetched per route.

Server state, cached

Reads go through the typed client and are cached and invalidated by the query layer, so the UI stays responsive and consistent without hand-rolled state plumbing.

Reads and writes are separated. The client calls read procedures for views and mutation procedures for actions. Mutations are the audited, idempotent ones — the Publish, Approve, Ratify clicks — and they flow to the same write-path the agents use. See Backend.

Auth in the client

The front end runs behind the hosting platform's identity layer: a signed-in user arrives with a client principal the app can read, and views are gated by role. The client never holds a database credential — it only ever calls the API, which does the privileged work on its behalf.

The API it calls → · Where it's hosted →