Architecture in the Frontend
You do not learn frontend architecture in a diagram.
You learn it in the next feature.
This site shows how modern frontend features can be built reactively, with clear cuts and maintainable responsibilities: with Angular, Signals, Resources, Stores, Facades, ViewModels, and templates that do not quietly become control flow engines.
Tactical Frontend Design
Most frontend problems do not begin with microfrontends, monorepos, or framework choices. They begin inside small features: filtering a list, loading a detail view, deleting a record, showing a notification, navigating after an action. That is where a system either stays reactive or slowly decays into callback chains, template logic, and component-owned state.
Retrieve Slice
Loading data is not just a GET. It is a cut through Resource, State, ViewModel, and UI.
Open lesson →Reactive Filter & Sorting
The UI sends intents. The ViewModel derives visible data.
Open lesson →Create / Update / Delete
Commands do not merely change data. They create state transitions, error paths, and UI decisions.
Open lesson →Optimistic Updates
When lists are too large, you do not reload everything. The client has to think cleanly for a while.
Open lesson →Programmatic Routing
Navigation is not a template side effect. It is part of the feature flow.
Open lesson →Global Events
Notifications, errors, and cross-cutting UI signals need boundaries.
Open lesson →Werkstattnotiz 01
Architecture From the Workshop
"It's just a filter."
"The component can handle that quickly."
"This feature does not need structure."
Maybe.
As long as the feature stays tiny, never fails, and never needs to grow.
Most frontends do not stay in that condition.
This site does not treat frontend architecture as a grand abstract goal. It shows it through recurring UI problems.
Fire protection still matters, but it does not start with microfrontend debates or monorepo ideology.
It starts where features slip: when templates begin making decisions, components quietly accumulate state, and commands start steering half a workflow.
What to explore after the lessons
Tactical Frontend Design
Lessons for concrete features and reactive UI flows.
Notes to Self
Short texts against bad frontend reflexes.
Thinking Errors
Sentences and assumptions that make projects expensive.
Decisions
Architecture as a context decision instead of a belief system.
Patterns
Building blocks that recur across multiple features.
You're in the right place if …
- → you want to understand why modern frontends should not be built imperatively like small backends
- → you no longer want to think about features as Component + Service + Subscription
- → you want to derive filtering, sorting, selection, loading, and error states cleanly
- → you want to place Angular Signals, Resources, and Stores architecturally
- → you have backend experience and want to understand why UI behaves differently
- → you are not looking for framework magic, but for repeatable cuts
One possible learning path
The site is not a linear manual. But if you want a sensible starting sequence, this one works surprisingly well.
Why frontend thinks differently
An entry into reactive development, UI state, and framework paradigms.
02Understand retrieve
Resource, Mapper, Store, Facade, ViewModel, Component.
03Make lists manageable
Filtering, sorting, selection, and derived state.
04Cut commands cleanly
Create, Update, Delete, errors, loading, and optimistic UI.
05Connect feature flows
Routing, notifications, global events, and side effects.
06Make architecture decisions
When patterns help and when they are only decoration.
From real projects
The lessons do not stay theoretical. The field reports show how decisions emerge under real project friction. The tournament app series is the best entry point.
From idea to architecture decision
Open report →First the skeleton, then the business logic
Open report →03Setup auth via Keycloak
Open report →04The first architecture drift
Open report →05UI and translation baseline before business logic
Open report →06The first vertical slice
Open report →07First code review after the breakthrough
Open report →08From CRUD to planning flow
Open report →Recommended starting points
Frontend is not backend in color
Why modern frontends need their own mental model and why strong backend reflexes can still fail in the UI.
ViewModel Aggregation
How UI meaning should come from derived state instead of leaking into templates.
PatternAnti-Corruption Layer
Why API language should not spill unfiltered into your components.
LessonRetrieve Slice
Loading data without component logic and without DTOs marching into the template.
LessonReactive Filter & Sorting
The list is not a component mutation. It is derived from query state and resource state.
ManifestoWhy this site?
What is here, why it is written this way, and who it is for.
Field ReportThe first vertical slice
How a concrete first pass shows that CRUD is only the beginning of a feature flow.