Frontend Architecture
The structural decisions in client applications — rendering strategy, state ownership, boundaries and delivery — which have the same character as backend ones and are frequently made by default.
Definition
Frontend architecture covers rendering strategy, state management, module boundaries, data fetching, and how code is delivered to the browser or device.
The decisions that matter
Rendering strategy, which is the one with the widest consequences:
| Strategy | Good for | Cost |
|---|---|---|
| Static generation | Content that changes rarely | Rebuild on change |
| Server rendering | First-load performance, SEO, low-capability devices | Server cost; more complex caching |
| Client rendering | Rich interaction after load | Slow first paint; poor on weak devices |
| Hybrid (server shell plus client hydration) | Most products | Complexity |
The decision is frequently made by framework default rather than by requirement, and it determines first-load performance for every user on a slow connection.
State ownership. Which state is server state (cached remote data with staleness), which is client state (UI concerns), and which is URL state (shareable, restorable). Conflating them is the most common source of frontend complexity — treating cached server data as if it were local state produces synchronisation bugs indefinitely.
Module boundaries, which have the same properties as backend ones: draw them where change correlates, not around technical layers.
Bundle strategy. What is loaded when. Code splitting by route is the baseline; everything shipped up-front penalises the first visit for functionality most users never reach.
The performance constraints that are architectural
- JavaScript is expensive on low-end devices — parsing and execution, not just download. A bundle that is fine on a developer's machine can take seconds on a mid-range phone.
- Round trips dominate on mobile networks. A screen requiring six sequential requests cannot be fast, which is the argument for aggregation close to the services.
- Third-party scripts are frequently the largest performance and reliability liability, and they are outside your control.
Failure scenarios
- Rendering strategy chosen by default rather than by requirement.
- Server state treated as client state, producing permanent synchronisation bugs.
- Everything in one bundle.
- Performance measured on fast devices and networks, so the users who suffer are invisible.
- Third-party scripts blocking render, with no budget or review.
Interview question
"What decides whether a product should render on the server or the client?"