The method: eight questions, in order

1. Users and scale — how many, where, on what devices and networks; peak versus average; anonymous versus authenticated share. 2. Discoverability and first paint — which routes must be indexed and fast on first visit (server-rendered or prerendered) and which are app-like behind a login (client-rendered). 3. Boundaries — the application shell (navigation, auth, error handling, telemetry) versus features behind lazy routes; which state is server state (cached API data), which is UI state (signals in components), which is URL state. 4. Contracts — the API shape, versioning, error envelope, pagination; validated at the edge of the frontend so a backend change fails loudly, not silently. 5. Caching and offline — HTTP cache headers and CDN, transfer cache for SSR, in-memory stale-while-revalidate, service worker for the shell and selected data; what the user sees offline. 6. Budgets — initial JavaScript, Largest Contentful Paint, Interaction to Next Paint, accessibility conformance; enforced in CI, not in a document. 7. Security — session mechanism, CSRF, CSP, sanitisation, dependency policy (module 63). 8. Operations — analytics events with a schema, error and performance telemetry with correlation (module 65), deployment topology (CDN + SSR servers or edge), rollback, cost.

Rendering model per route

Marketing and catalogue pages: prerendered where the set is finite, server-rendered with cache for the long tail; the account area: client-rendered behind authentication; a shared shell hydrated incrementally. Angular expresses this per route with RenderMode (module 46); the first example configures a small platform that way and renders its server route. The cost model in the second example makes the trade-off explicit: SSR costs compute per request, prerender costs build time and staleness, CSR costs first-paint latency and SEO.

Application shell and state boundaries

The shell owns cross-cutting concerns: layout, navigation, auth session, global error handling, telemetry, the service worker. Features are lazy routes with their own providers (module 24). State: server state lives in a cache keyed by request (resource/httpResource or a small store with stale-while-revalidate), UI state in component signals, navigation state in the URL; a global store only for truly shared, long-lived client state (module 55). The shell skeleton in the first example shows these seams with the smallest honest implementation.

API contracts and runtime validation

TypeScript types describe the contract at compile time; nothing checks it at runtime unless you do. A validator at the HTTP boundary (a small schema in the third example; zod/valibot in production) turns a backend change into a reported contract error with the field path, instead of a TypeError three components later (the first mistake). Version the contract (Accept: application/vnd.academy.v2+json or a path prefix), keep an error envelope ({ code, message, correlationId }), and test the contract from the frontend side with recorded fixtures.

Caching, offline and resilience

Layers: CDN for static assets and prerendered HTML; HTTP cache headers for API GETs (Cache-Control: private, max-age or ETags); the SSR transfer cache so the browser does not refetch what the server fetched; an in-memory stale-while-revalidate cache for navigations back to known data; the service worker for the shell and an explicit allow-list of data (module 49). Offline: show cached data with a banner, queue mutations only when idempotent. Resilience: timeouts, bounded retries with backoff for idempotent requests (module 60), circuit-breaking for a failing dependency, and a degraded mode that still renders.

Budgets, security, analytics, observability, deployment, cost

Budgets in angular.json and in CI (initial bundle, per-route chunks); Web Vitals targets (LCP < 2.5 s, INP < 200 ms, CLS < 0.1) measured in the field; WCAG 2.2 AA with automated and manual checks (module 44). Security posture from module 63. Analytics as a typed event schema with a consent gate. Observability from module 65. Deployment: CDN in front, SSR on Node servers or at the edge, blue/green or canary with the dashboard watching (module 65), rollback by artefact hash. Cost: the calculator in the second example — compute per request for SSR, build minutes for prerender, bandwidth for everything.

Reasoning task and rubric (the review artefact for the non-runnable parts)

Why execution is not applicable: the rendering-model decision, the deployment topology and the cost model are decisions about an organisation's traffic, team and budget; they are reasoned and reviewed, not compiled. Task: design the Interview Prep Academy platform for 50,000 daily learners (70% anonymous browsing the catalogue, 30% signed in practising), with search-engine discovery of lessons, offline revision on mobile, and a two-person platform team. Produce: (1) a route table with a render mode and a reason per route; (2) the shell/feature boundary with the state each side owns; (3) the API contract list with validation points and the error envelope; (4) the cache and offline policy per data type; (5) budgets with numbers; (6) the security and telemetry checklist; (7) the deployment diagram and a monthly cost estimate from the calculator; (8) three alternatives you rejected and why. Rubric (score each 0–2): requirements restated with numbers · render mode per route justified by discoverability and auth · boundaries make lazy loading and ownership obvious · contracts validated at the edge with an error envelope · caching layered with offline behaviour stated · budgets concrete and enforced in CI · security posture names session, CSRF, CSP, sanitisation, dependencies · observability correlates errors, traces and releases · cost model shows the trade-off between SSR compute and prerender staleness · alternatives are real and the rejection reasons are specific. 16+ of 20: principal-level; 12–15: senior; below 12: revisit the referenced modules.

Industry scenario

A learning platform rendered everything on the client; lessons were invisible to search engines and the first paint on mobile took 6 s. The redesign prerendered the catalogue, server-rendered lesson pages with a 5-minute cache, kept the practice area client-rendered behind login, validated the API at the boundary (which caught a silent pagination change two weeks later), and put budgets in CI. Organic traffic tripled; the SSR bill was a few hundred dollars a month — the calculator predicted it within 20%.