Frontend Architecture
Putting it together: architect a frontend
Reading about the cascade is not the same as designing with it. Architect a real app where every layer has to coexist — and where a wrong call low in the stack will surface as a symptom you have to trace back. This is the capstone: make the six decisions, then prove each one against evidence, not taste.
Turn the whole track into one coherent architecture: a deliberate state model, a fetch layer that protects LCP, accessible forms, a semantic token system, clean monorepo packaging, and a code-split build — each decision justified by the layer it owns and verified with a measurement or a check.
Design and build a small but realistic multi-view frontend app (e.g. a dashboard with a list view, a detail view, an accessible create/edit form, and a heavy analytics tab) that makes a defensible decision at every track layer — state shape, data fetching, forms/a11y, design tokens, monorepo packaging, and a code-split build — and prove the architecture holds with metrics and checks rather than assertions.
- A state-ownership table classifying every piece of state as server-cache / global / local with a one-line justification, and a profile (React DevTools or equivalent) showing that typing in the search box re-renders only the search subtree, not the whole view.
- A before/after of the detail-view fetch graph — a waterfall diagram or network trace — showing independent requests overlapping, plus a measured LCP under 2.5 s on a throttled mid-tier profile.
- An accessibility pass on the form: a keyboard-only walkthrough (tab order, focus on error, escape closes), a screen-reader read-out of one error path, and an automated axe (or equivalent) run with zero critical violations.
- A theme switch from light to dark that changes only token values — demonstrated by a diff showing component files untouched — and a simulated rebrand that changes one primitive and cascades everywhere.
- A CI demonstration: a one-package change builds/tests only the affected package(s) and hits the cache for the rest, with the task graph or timing shown before and after the boundary work.
- A bundle report (e.g. the bundler's analyzer or Chrome Coverage) proving the heavy analytics library is absent from the initial chunk and loads only when the analytics tab is opened.
- Add an allocation-of-failure exercise: deliberately introduce one bug per layer (keystroke in global store, an `enabled`-gated independent fetch, a hardcoded hex, a static import of the heavy chart) and write the review note that traces each symptom to its owning layer.
- Add a Lighthouse CI gate that fails the build if LCP regresses past 2.5 s or if the initial bundle grows beyond a budget, so the fast path cannot silently rot.
- Add an a11y CI gate (axe in the test suite) that fails on any new critical violation in the form components.
- Implement a runtime theme switcher (light/dark/high-contrast) backed purely by swapping the semantic token mapping, and prove a third theme costs no component edits.
- Add a remote cache shared across machines and measure the cold-vs-warm CI time difference, mirroring the Mercari result of roughly halved task duration.
This is the architecture review you will run on every real frontend, performed proactively at design time instead of reactively in a postmortem. Make each of the six decisions deliberately — colocate volatile state, parallelise the fetch graph, build accessible forms, layer tokens primitive-to-semantic, draw real package boundaries, code-split the heavy and rare — and prove each with evidence at the layer it owns. Doing it once on a small app makes the failure-cost cascade muscle memory, so on the next janky dashboard you reach for the state shape, not the bundle.