Welcome back to the React Mastery Series!
We’ve completed the first 30 days of our React journey.
So far, we’ve covered:
- React Fundamentals
- Components & Props
- Hooks
- Context API
- Redux Toolkit
- API Integration
- Forms & Validation
- Performance Optimization
- Testing
- Authentication & Authorization
- Design Patterns
- Error Handling
- Enterprise Project Structure
Now it’s time to move from:
“How do I build a React application?”
to:
“How do I architect a React application that can scale?”
This is where the responsibilities of a Senior Frontend Engineer / Frontend Architect begin.
What Does “Large-Scale React Application” Mean?
A small React application might have:
10–50 Components
5–10 Pages
2–3 Developers
Enter fullscreen mode Exit fullscreen mode
A large enterprise application might have:
1000+ Components
100+ Pages
Multiple Business Domains
Multiple Teams
Multiple APIs
Multiple Environments
Millions of Users
Enter fullscreen mode Exit fullscreen mode
At this scale, writing good components isn’t enough.
We need a clear architecture.
The Architecture Problem
Imagine a banking application containing:
Accounts
Cards
Payments
Loans
Investments
Transactions
Notifications
Customer Support
Enter fullscreen mode Exit fullscreen mode
If every feature can directly access everything else:
Accounts
↕
Payments
↕
Cards
↕
Loans
↕
Investments
Enter fullscreen mode Exit fullscreen mode
The application eventually becomes tightly coupled.
One feature starts depending on another.
Changes become risky.
The Goal of Architecture
A good architecture should provide:
Low Coupling
+
High Cohesion
+
Clear Boundaries
+
Reusable Components
+
Testability
+
Scalability
Enter fullscreen mode Exit fullscreen mode
Let’s understand each one.
1. High Cohesion
Code that belongs together should stay together.
For example:
features
└── payments
├── components
├── hooks
├── services
├── types
└── utils
Enter fullscreen mode Exit fullscreen mode
Everything related to payments is located inside the payments domain.
This is high cohesion.
2. Low Coupling
Features shouldn’t unnecessarily depend on each other’s internal implementation.
Bad:
Payments
↓
Accounts Internal Component
↓
Accounts Internal Service
Enter fullscreen mode Exit fullscreen mode
Better:
Payments
↓
Accounts Public API
Enter fullscreen mode Exit fullscreen mode
The payments feature only knows what it needs to know.
Public APIs Between Features
One useful technique is to expose only the functionality that other features need.
Example:
accounts
├── components
├── hooks
├── services
├── types
└── index.ts
Enter fullscreen mode Exit fullscreen mode
The index.ts acts as a public entry point.
export { AccountSummary } from "./components/AccountSummary";
export { useAccounts } from "./hooks/useAccounts";
export type { Account } from "./types";
Enter fullscreen mode Exit fullscreen mode
Other features can import from:
import {
AccountSummary,
useAccounts,
} from "@/features/accounts";
Enter fullscreen mode Exit fullscreen mode
Instead of reaching into internal files:
import { AccountSummary } from "@/features/accounts/components/internal/AccountSummary";
Enter fullscreen mode Exit fullscreen mode
This creates a clear boundary.
Feature-Driven Architecture
A large React application can be organized around business domains.
src
├── app
├── features
│ ├── auth
│ ├── accounts
│ ├── cards
│ ├── payments
│ ├── loans
│ └── investments
├── shared
├── layouts
└── routes
Enter fullscreen mode Exit fullscreen mode
This is often easier to scale than organizing everything by technical type.
Layered Architecture Inside a Feature
A feature can also have internal layers.
payments
├── components
├── hooks
├── services
├── store
├── types
├── validation
└── utils
Enter fullscreen mode Exit fullscreen mode
Each layer has a responsibility.
Components
UI and presentation.
Hooks
Reusable React behavior.
Services
Communication with APIs and external systems.
Store
Feature-specific state.
Types
TypeScript models.
Validation
Input and business validation rules.
Utils
Pure helper functions.
Clean Architecture Concepts
Clean Architecture separates business rules from infrastructure.
A simplified React interpretation looks like:
UI Layer
↓
Application Layer
↓
Domain Layer
↓
Infrastructure Layer
Enter fullscreen mode Exit fullscreen mode
Let’s understand this.
UI Layer
Responsible for:
- Rendering
- User interactions
- Navigation
- Visual states
Example:
function PaymentForm() {
const { submitPayment, isSubmitting} = usePayment();
return (
<form onSubmit={submitPayment}>
{/* Form UI */}
</form>
);
}
Enter fullscreen mode Exit fullscreen mode
The component shouldn’t know how the backend works.
Application Layer
This layer coordinates application behavior.
Example:
function usePayment() {
const submitPayment = async ( payment: PaymentRequest) => {
return paymentService.createPayment(payment);
};
return {submitPayment};
}
Enter fullscreen mode Exit fullscreen mode
The hook coordinates the UI with the underlying services.
Domain Layer
The domain contains business concepts and rules.
For example:
type Payment = {
amount: number;
currency: string;
accountId: string;
};
Enter fullscreen mode Exit fullscreen mode
Business rules might include:
function canMakePayment( balance: number, amount: number) {
return balance >= amount;
}
Enter fullscreen mode Exit fullscreen mode
This logic shouldn’t depend on React.
Infrastructure Layer
This layer communicates with external systems.
Examples:
- REST APIs
- GraphQL
- Browser storage
- Analytics
- External SDKs
Example:
export async function createPayment(payment: PaymentRequest) {
const response = await api.post("/payments",payment);
return response.data;
}
Enter fullscreen mode Exit fullscreen mode
Why Separate These Layers?
Imagine the backend changes from:
REST API
Enter fullscreen mode Exit fullscreen mode
to:
GraphQL
Enter fullscreen mode Exit fullscreen mode
If API implementation is isolated:
UI
↓
Application
↓
Domain
↓
GraphQL Service
Enter fullscreen mode Exit fullscreen mode
We can replace the infrastructure without rewriting the entire UI.
That’s the power of separation of concerns.
Dependency Direction
A key architectural principle is:
Dependencies should point toward stable business logic.
Instead of:
Component
↓
Axios
↓
API
↓
Business Rules
Enter fullscreen mode Exit fullscreen mode
Prefer:
UI
↓
Application
↓
Domain
Infrastructure
↓
Implements External Communication
Enter fullscreen mode Exit fullscreen mode
This makes business logic easier to test.
Dependency Injection Concept
React doesn’t have traditional dependency injection like Angular.
However, we can implement similar concepts using:
- Props
- Context
- Factory functions
- Interfaces
- Provider patterns
For example:
type PaymentService = { createPayment: (
payment: PaymentRequest
) => Promise<Payment>;
};
Enter fullscreen mode Exit fullscreen mode
The hook can receive the service:
function createPaymentController(service: PaymentService) {
return {
submitPayment: (
payment: PaymentRequest
) => service.createPayment(payment),
};
}
Enter fullscreen mode Exit fullscreen mode
Now testing becomes easier because we can inject a mock service.
Testing Becomes Easier
Without separation:
Component
↓
Axios
↓
Backend
Enter fullscreen mode Exit fullscreen mode
Testing requires mocking multiple dependencies.
With separation:
Component
↓
Controller
↓
Interface
↓
Mock Service
Enter fullscreen mode Exit fullscreen mode
We can test business behavior without making real network requests.
State Management Architecture
Not every piece of state belongs in Redux.
A useful rule is:
Local State
Use for:
Modal visibility
Input values
Temporary UI state
Enter fullscreen mode Exit fullscreen mode
Context
Use for:
Theme
Authentication
Localization
Enter fullscreen mode Exit fullscreen mode
Server State
Use tools such as:
TanStack Query
Enter fullscreen mode Exit fullscreen mode
for:
API data
Caching
Refetching
Synchronization
Enter fullscreen mode Exit fullscreen mode
Global Client State
Redux Toolkit can be useful for:
Complex shared application state
Cross-feature workflows
Client-side business state
Enter fullscreen mode Exit fullscreen mode
Don’t Put Everything in Redux
A common architectural mistake is:
Everything
↓
Redux
Enter fullscreen mode Exit fullscreen mode
This creates unnecessary complexity.
Instead:
UI State
↓
useState
Shared Context
↓
Context API
Server State
↓
TanStack Query
Complex Global State
↓
Redux Toolkit
Enter fullscreen mode Exit fullscreen mode
Choose the simplest appropriate tool.
Shared Components
Enterprise applications usually have a design system.
Example:
shared
└── components
├── Button
├── Input
├── Modal
├── Table
├── DatePicker
└── Notification
Enter fullscreen mode Exit fullscreen mode
These components should be:
- Reusable
- Accessible
- Consistent
- Well tested
Don’t Put Business Logic in Shared Components
A shared Button shouldn’t know about payments.
Bad:
<Button
onClick={submitPayment}
paymentType="INTERNATIONAL"
accountId={accountId}
/>
Enter fullscreen mode Exit fullscreen mode
The button should only care about being a button.
Business logic belongs in the feature.
Domain Boundaries
Think about each feature as a small business domain.
Payments
│
├── Payment Form
├── Payment API
├── Payment Validation
└── Payment State
Enter fullscreen mode Exit fullscreen mode
The payments domain owns its own logic.
This makes teams more independent.
Architecture for Multiple Teams
Imagine four teams:
Team A → Accounts
Team B → Payments
Team C → Cards
Team D → Investments
Enter fullscreen mode Exit fullscreen mode
A feature-based architecture allows each team to work within its domain.
Accounts Team
↓
features/accounts
Payments Team
↓
features/payments
Cards Team
↓
features/cards
Enter fullscreen mode Exit fullscreen mode
This reduces conflicts and improves ownership.
When the Application Becomes Very Large
Eventually, even a well-structured monolithic React application can become difficult to manage.
At that point, organizations may consider:
Modular Monolith
↓
Micro Frontends
Enter fullscreen mode Exit fullscreen mode
Micro Frontends allow independently developed frontend modules to be composed into a larger application.
For example:
Shell Application
│
├── Accounts
├── Payments
├── Cards
└── Investments
Enter fullscreen mode Exit fullscreen mode
However:
Micro Frontends should solve an organizational or deployment problem—not simply be introduced because the application is large.
Architecture Decision Framework
Before introducing a new technology, ask:
What problem are we solving?
↓
How frequently does this problem occur?
↓
How many teams are affected?
↓
What complexity does the solution introduce?
↓
Is the benefit greater than the cost?
Enter fullscreen mode Exit fullscreen mode
This is architectural thinking.
Example Enterprise Architecture
A mature React application might look like:
┌──────────────────────────────┐
│ React UI │
├──────────────────────────────┤
│ Components / Pages / Routes │
├──────────────────────────────┤
│ Application Services │
├──────────────────────────────┤
│ Domain Logic │
├──────────────────────────────┤
│ Infrastructure / API Layer │
├──────────────────────────────┤
│ REST / GraphQL / External │
│ Services │
└──────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode
This separation makes the application easier to evolve.
Common Architectural Mistakes
1. Overengineering
Don’t introduce:
10 Layers
20 Abstractions
5 State Libraries
Enter fullscreen mode Exit fullscreen mode
for a simple application.
Architecture should match the problem.
2. Creating a Global Utility for Everything
A huge utils.ts file eventually becomes difficult to understand.
Group utilities by domain when appropriate.
3. Excessive Shared Code
Sharing code is useful.
But excessive sharing creates coupling.
Sometimes duplication is cheaper than creating a tightly coupled abstraction.
4. Mixing Infrastructure with Business Logic
Avoid:
Component
↓
Axios
↓
Business Rules
Enter fullscreen mode Exit fullscreen mode
Keep infrastructure replaceable.
Senior Engineer Mindset
A junior developer often asks:
“How can I implement this feature?”
A senior developer asks:
“Where should this feature belong?”
An architect asks:
“How will this decision affect the system six months from now?”
That shift in thinking is extremely important.
Architecture Checklist
Before adding a new feature, ask:
- What business domain does it belong to?
- What state does it require?
- Is that state local or global?
- Does it require server data?
- Where should API communication live?
- Can the logic be reused?
- What should be publicly exposed?
- How will it be tested?
- What happens when the API fails?
- Will this architecture scale to additional teams?
Key Takeaways
Today, we learned:
✅ Large React applications need clear architectural boundaries.
✅ Feature-based architecture improves scalability and ownership.
✅ High cohesion and low coupling are fundamental principles.
✅ Clean Architecture separates UI, application, domain, and infrastructure concerns.
✅ Not every piece of state belongs in Redux.
✅ Dependency injection concepts can improve testability even in React.
✅ Micro Frontends should be introduced only when they solve a real organizational or deployment problem.
✅ Good architecture is about managing complexity, not adding complexity.
Coming Next 🚀
In Day 32, we’ll take the next step toward frontend architecture:
State Management Architecture – Redux Toolkit vs Context API vs TanStack Query
We’ll answer some of the most common questions senior React developers face:
- When should I use Context API?
- When should I use Redux Toolkit?
- When should I use TanStack Query?
- What is client state vs server state?
- Where should authentication state live?
- How should multiple features share state?
- How do we avoid unnecessary re-renders?
- How should state management be designed in an enterprise React application?
We’ll build a practical decision framework rather than simply comparing libraries.
Happy Coding! 🚀
답글 남기기