Layered Frontend Architecture
Small apps survive any folder structure. Large ones need clear boundaries so that a change in one place does not ripple everywhere. A layered, feature-first architecture is the most common answer senior engineers give in interviews. A layered frontend architecture is an application of separation of concerns.
1. Organize by feature, not by file type
// By type (breaks down at scale)
components/ hooks/ services/ utils/
// By feature (scales)
features/
checkout/
CheckoutView.tsx
use-checkout-view-model.ts
checkout.service.ts
checkout.types.ts
search/
...
shared/
ui/ // design-system primitives (Button, Modal)
lib/ // pure helpers (formatCurrency)
api/ // http client with auth, retries, timeoutsEverything a feature needs lives together, so it can be understood, tested, or deleted as a unit.
2. The layers
| Layer | Responsibility | Depends on |
|---|---|---|
| UI (views, components) | Render state, forward user intent | View models, shared UI |
| View model / hooks | UI state, derived data, commands | Services |
| Services / use cases | Business rules, orchestration | Repositories / API client |
| Repositories / API client | HTTP, storage, mapping DTOs to domain models | Nothing app-specific |
Dependencies point one way:... premium content.
