Next.js
/Intermediate
Feature-Based Architecture
Definition
An organizational pattern where files are grouped by the 'Feature' they belong to (e.g., all Auth files together), rather than by their file type (e.g., all Components together).
Explain Like I'm New
The old way: A `components` folder for all UI, a `hooks` folder for all logic, and an `api` folder for all endpoints. This is a nightmare to navigate. The new way (Feature-based): A `features/auth` folder that contains the auth components, the auth hooks, and the auth API all in one place.
Real World Example
If you need to delete the 'Shopping Cart' feature from your app, you don't have to hunt down 10 different files spread across the codebase. You just delete the single `features/cart` folder.
Common Use Cases
- •Large codebases
- •Team collaboration
- •Scalability
Terminal Output
bash / terminal
/*
❌ BAD: Type-Based Architecture (Constant jumping between folders)
src/
├── components/
│ ├── LoginForm.tsx
│ └── ProductCard.tsx
├── hooks/
│ ├── useAuth.ts
│ └── useCart.ts
└── api/
├── login.ts
└── checkout.ts
✅ GOOD: Feature-Based Architecture (Everything is self-contained)
src/
├── features/
│ ├── auth/
│ │ ├── components/LoginForm.tsx
│ │ ├── hooks/useAuth.ts
│ │ └── api/login.ts
│ │
│ └── cart/
│ ├── components/ProductCard.tsx
│ ├── hooks/useCart.ts
│ └── api/checkout.ts
*/
Interview Questions
basic
- What is the primary benefit of grouping code by Feature rather than by File Type?
intermediate
- How does Colocation in the Next.js App Router naturally encourage Feature-Based Architecture?