Frontend Architect Foundation Map
Why this chapter matters
Part 0 is the base layer for the whole book. A frontend architect does not only know React, CSS, or build tools. They understand how product intent becomes browser behavior under real constraints: latency, device limits, accessibility, security, data freshness, ownership, release risk, and team scale.
This chapter gives you the map. The rest of Part 0 fills in the operating skills.
The baseline expectation
Before architect-level system design, you should be able to reason across ten foundations:
| Foundation | Architect-level question |
|---|---|
| Product and user intent | What user outcome is protected, and what failure would users actually feel? |
| Browser runtime | What work happens on the main thread, network, storage, compositor, and accessibility tree? |
| Rendering and data | Which state belongs in URL, server cache, client cache, local storage, or component memory? |
| Interaction design | What happens across loading, empty, error, partial, disabled, pending, and recovery states? |
| Accessibility | Can the workflow be completed with keyboard, screen reader, zoom, reduced motion, and constrained cognition? |
| Security and privacy | What input, script, storage, identity, and third-party boundaries are trusted or untrusted? |
| Performance | What is the route-level cost in bytes, CPU, network, rendering, and user-perceived latency? |
| Verification | Which tests, budgets, audits, traces, and production signals prove the behavior survives release? |
| Delivery | How do build, deploy, rollback, flags, experiments, and dependencies change risk? |
| Ownership | Who can change the surface, who approves exceptions, and who responds when it fails? |
If one of these is missing, the architecture decision is probably incomplete.
The frontend architect's mental stack
Business goal
-> user journey
-> interaction contract
-> data and permission model
-> rendering and runtime strategy
-> component and module boundaries
-> quality gates
-> release and rollback plan
-> production telemetry
-> ownership and evolution
Framework features enter late in this stack. They matter, but they implement decisions rather than replace them.
The four contracts of a frontend surface
Every important frontend surface has four contracts.
1. User contract
The user contract defines what the user can expect.
- What can they accomplish?
- What state is visible?
- What can fail?
- How do they recover?
- What works on slow devices, small screens, assistive technology, or poor networks?
2. Data contract
The data contract defines truth and freshness.
- Who owns the data?
- How fresh must it be?
- What happens when reads are stale?
- What happens when mutations fail?
- How are permissions enforced?
- What data can be cached, logged, or stored locally?
3. Runtime contract
The runtime contract defines browser and delivery behavior.
- What renders on the server, edge, or client?
- What JavaScript must run before the user can act?
- What code is shared across routes?
- Which APIs, workers, caches, and storage layers are used?
- How does the surface degrade?
4. Team contract
The team contract defines change.
- Who owns the route, module, API, component, and quality gates?
- What changes require review?
- What standards apply?
- What exceptions exist?
- When is debt revisited?
Foundation maturity rubric
| Level | Behavior |
|---|---|
| Developing | Can implement features but mostly reasons from component code and framework examples. |
| Strong senior | Can reason about route behavior, state ownership, accessibility, performance, and production failure. |
| Staff-ready | Can define contracts, tradeoffs, quality gates, and migration paths across multiple teams or surfaces. |
| Architect-ready | Can create decision systems that make other teams faster and safer without becoming the bottleneck. |
Minimum artifact set
A frontend architect should be comfortable producing these artifacts before moving into later parts of the book:
| Artifact | Purpose |
|---|---|
| Route architecture note | Rendering mode, data dependencies, cache/freshness, failure states, budgets |
| Interaction state matrix | Loading, empty, error, pending, offline, unauthorized, partial success |
| State ownership map | URL, server, client cache, local durable storage, component state |
| Accessibility contract | Keyboard, focus, semantics, names, live regions, reduced motion |
| Threat boundary sketch | User input, third-party scripts, storage, auth/session, dangerous sinks |
| Performance budget | Route bytes, LCP, INP, CLS, expensive interactions, monitoring |
| Verification plan | Tests, checks, manual review, field metrics, rollback signal |
| Ownership register | Owner, approver, exception, expiry, escalation path |
How to use Part 0
Read Part 0 in this order if you want a broad foundation:
- Foundation map and senior mindset.
- Performance, browser runtime, forms, security, testing, tooling, and observability.
- Domain/data/state modeling and production readiness.
- Weakness diagnosis, transition mistakes, debugging drills, ownership exercises, and architect thinking.
- Advanced platform frontiers after the baseline is comfortable.
Do not rush to framework-specific architecture before you can explain the route, data, runtime, user, and ownership contracts without naming a framework.
Exercises
- Pick one production route and fill out the four contracts: user, data, runtime, and team.
- Create the minimum artifact set for one feature you already know well.
- Mark each foundation area as weak, usable, strong, or teachable.
- Choose one weak area and define a two-week practice loop with a concrete output.