Every Frontend Architecture Pattern, Explained

THE CONCEPTS

The mental models, one by one

1. 01

   Static Pages

   The web started as static HTML and CSS with a sprinkle of JavaScript. Fast, cheap, zero interactivity.

   Think of a newspaper: text and images, no reaction to the user. Every architecture that came after exists because we wanted more than that.

   HTMLCSSZero interactivity
2. 02

   MVC — Model, View, Controller

   The model and controller run on the server. PHP, Python or Java mix data into templates and spin out tailored HTML. Django, Rails and .NET all started here.

   More dynamic than static pages, but every click reloads the page, the backend and frontend are tightly coupled, and switching frameworks is close to impossible.

   Server renderingTemplatesTight coupling
3. 03

   The Single Page Application

   Then JavaScript happened. Logic moved to the browser: state, validation, even auth checks. The backend became a data API. The frontend engineer was born.

   Rich interactivity, no page reloads, complex products like dashboards became possible. The price: too much JavaScript, slow first loads and poor SEO — the browser has to download and parse everything before showing anything.

   Know the thick vs thin client trade-off: a thin client delegates logic to the server; a thick client owns the logic and uses the backend as storage. Be able to argue how thick your client should be.

   React / Vue / AngularClient stateThick vs thin clients
4. 04

   BFF — Backend For Frontend

   Mobile arrived and every client wanted the same data in a different shape. One shared API becomes a Frankenstein.

   The fix: each frontend gets its own backend, owned by the frontend team. Auth, HTTPS and aggregation are implemented once, in the BFF. Backend teams ship microservices behind it, frontend teams ship features on top of it.

   GraphQL often lives here — it solves REST's overfetching and underfetching, at the price of new problems: the N+1 problem, schema design, caching.

   BFFGraphQLOverfetching / underfetchingAPI aggregation
5. 05

   SSG & ISR — Static Site Generation

   Back to the future: use a modern framework, but ship static pages from a CDN. Blazing fast, cheap, great SEO. The catch: no interactivity, and content changes need a rebuild.

   ISR fixes the rebuild: pages regenerate on a TTL. A request past the time window triggers a re-render from the data store and the CDN cache gets replaced.

   SSGISRCDNTTL
6. 06

   SSR & Hydration

   Run your JavaScript framework on the server, pre-render the initial HTML, send it down. No more empty white screen.

   But pre-rendered HTML is dead HTML. The browser still downloads the bundle, builds the component tree, and attaches it to the markup — that's hydration. Users see something fast, but interactivity is delayed. They click, nothing happens.

   SSRHydrationNext.js / NuxtWhite screen of death
7. 07

   React Server Components

   The last stage: strip the component tree of everything that isn't interactive. The server tree is the full one; the client tree is much smaller.

   You ship only the JavaScript you need, so hydration is fast and interactivity comes early. Default in modern Next.js. Explain when to use them and you're ahead of most candidates.

   RSCZero JS componentsIslands architecture
8. 08

   The Modular Frontend Monolith

   SPAs got huge. Three hundred developers in one codebase means someone breaks something every day.

   The fix is boundaries: shared UI, design system and services (auth, data fetching, logging) owned by a platform team; features built in domain teams — users, payments — with the folder structure to match.

   The hard part isn't drawing the domains. It's the discipline to keep dependencies from leaking across them.

   Domain boundariesPlatform teamDesign system
9. 09

   Clean & Hexagonal Architecture on the Frontend

   Onion thinking: your business domain sits stable at the center, frameworks depend on it — not the other way around. Swap React for Vue and most code survives.

   Honest answer for the frontend: it's usually overengineering. Frameworks are already opinionated, the client is thin, and you almost never actually swap frameworks. Reserve it for very large or very long-lived projects — but learn it, because it teaches you what decoupled code looks like.

   Clean architectureHexagonalDomain-driven designWhen NOT to
10. 10

    Micro-Frontends

    Take the domains and deploy them as independent applications, composed at runtime by a shell that owns shared CSS and global state. Teams own vertical slices — frontend and BFF — and deploy independently.

    This is how thousands of engineers work on one client app. It's also how small teams shoot themselves in the foot: the complexity tax is enormous and performance takes a hit from runtime composition (module federation).

    Interviewers ask about it even at small companies. Know how it works and — more important — when it doesn't make sense.

    Module federationShellIndependent deploysConway's law
11. 11

    The Frontend Architecture Audit

    Sit down with your current codebase and answer three questions: what is our architecture style, why did we land there, and what would the natural next step be.

    Then upgrade your interview answer. Not "we use React and Next.js" but: "We serve static pages via SSG, use SSR for personalization, structure the repo as a modular monolith, and considered micro-frontends as we scale."

    That's the difference between a mid-level answer and a senior one — and it's how you avoid the polite rejection email.

    Interview prepTrade-off thinking