Skip to content
Frontend Architecture

Architecture in the Frontend

Frontend architecture in practice

Frontend architectureyou can see in the code.

From state and feature flows to boundaries and responsibilities, this site explains the deeper ideas behind frontend architecture that holds up—clearly, concretely, and without framework hype.

For people who do not just build frontends, but also want to understand and explain the decisions behind them.

Recommended reading pathWhat This Site Stands For
# FEATURE FLOW DIAGNOSTIC
[FLOW]The UI sends intents.The feature reacts instead of wiring callbacks.
[STATE]Loading, filtering, and selection are state.Not side jobs of the component.
[BOUNDARIES]Resource, Store, Facade, and Mapper have distinct jobs.The decision is visible in the code.
[VERDICT]Architecture does not begin with the big diagram.It begins at the next concrete boundary.
Recommended reading path

New here? Start with these four steps.

This site is not a linear manual. But many of its ideas build on each other. This path starts with a frontend mental model and ends with concrete architecture decisions.

  1. 01

    Think about frontend differently

    Start with the mental model behind reactive UIs and state that belongs to the frontend.

    Read Frontend is not backend →
  2. 02

    Separate responsibilities in the code

    See how clear boundaries become visible inside a frontend feature.

    Open Tactical Frontend Design →
  3. 03

    Understand feature flows

    Follow a Retrieve Slice from its external resource to the ViewModel on screen.

    Read the Retrieve Slice →
  4. 04

    Question your reflexes

    Examine plausible assumptions that make frontends needlessly expensive over time.

    Explore misconceptions →
What this is about

Deep enough to understand. Concrete enough to apply.

Architecture terms are easy to name. The hard part starts when a project needs an actual decision: Where does the state live? Who knows about the ViewModel? Where does a command begin? Which boundary protects the domain?

That is why frontend-architekt.de connects the ideas behind an architecture to the boundaries where they become visible in code. Not as a universal recipe, but as a reasoned basis for making better decisions.

Core topics

What you will find here

Strategic Frontend Design

How to divide domain boundaries, teams, and frontends so systems can be developed and changed independently.

Explore strategic design

Tactical Frontend Design

How to organize state, commands, ViewModels, and feature flows in code within a boundary.

Explore tactical design

Think Pieces

Compact models and reminders for architecture decisions that keep returning in day-to-day project work.

Read the think pieces

Misconceptions

Plausible assumptions that make frontends expensive, unclear, or difficult to change over time.

Examine the misconceptions
Further perspectives

Go deeper and put it to work

These formats complement the core topics with decisions in context, recurring building blocks, and lessons from real projects.

01

Decisions

Architecture in context, not as a matter of faith.

Weigh the decisions →02

Patterns

Recurring solution building blocks with explicit boundaries.

Examine the patterns →03

Field Reports

Architecture decisions under real project conditions.

Read the field reports →
Curated selection

Recommended articles

Six articles, six ways in. Not the entire site at once—just a useful next thought.

Think Piece

When the frontend fights its framework

Why a UI is not a linear chain of commands, but a continuously updated projection of state.

Strategic Series

Microfrontends Under Real-World Conditions

Architecture decisions about size, communication, versioning, and framework autonomy beyond the happy path.

Tactical lesson

Retrieve Slice

How data flows through Resource, Mapper, Store, Facade, and ViewModel into the UI without getting stuck in the component.

Pattern

ViewModel Aggregation

Why UI meaning comes from derived state instead of being assembled in the template.

Misconception

Architecture takes too much time

Why skipping architecture does not remove cost—it only moves it into later changes.

Decision

Which architecture, when?

A way to make decisions where context helps more than a favorite pattern.