feat: New post

content/posts/seperation-of-concern-in-nextjs.md

@@ -0,0 +1,141 @@
+---
+author: ["Saurav Dhakal"]
+title: "Understanding Separation of Concerns (SoC) in NestJS"
+date: "2025-08-19"
+summary: "A guide to understanding Separation of Concerns in NestJS using modules, services, and controllers."
+tags: ["nestjs", "typescript", "architecture"]
+categories: ["Backend Development", "NestJS"]
+series: ["NestJS"]
+ShowToc: true
+TocOpen: false
+---
+
+When building applications, one of the most important design principles to keep in mind is **Separation of Concerns (SoC)**. NestJS, with its modular architecture, makes applying SoC almost effortless — but understanding _why_ it matters and _how_ to use it properly will help you write cleaner, testable, and future-proof code.
+
+## What is Separation of Concerns and Why it Matters?
+
+The basic idea is:
+
+> A program should be divided into distinct sections, where each section addresses a single responsibility.
+
+In simpler terms:
+
+- Every part of the code should have **one clear job**.
+- This makes the code easier to **understand, test, and maintain**.
+
+Lets take an analogy of a coffee shop to better understand this concept. A coffee shop has multiple employees with distinct roles:
+
+- The **cashier** handles payments.
+- The **barista** makes coffee.
+- The **inventory manager** tracks beans and supplies.
+
+If one person did everything, the system would collapse into chaos. The same goes for software. Each role has a single responsibility, and no one does everything.
+
+Suppose you’re building an **eCommerce platform**. Without SoC, all the logic might end up in one massive file — authentication, product catalog, payments, inventory, order processing. This quickly becomes **spaghetti code**: hard to read, impossible to test, and dangerous to modify.
+
+With **Separation of Concerns**, you break it down into modules:
+
+- **Auth Module** → Handles user registration, login, JWT tokens.
+- **Products Module** → Manages product catalog and search.
+- **Checkout Module** → Orchestrates payment and order creation.
+- **Inventory Module** → Keeps track of stock levels.
+
+Each module **does one thing**. When you need to upgrade your payment provider or switch databases, you only touch the **Checkout Module** or **Inventory Module** — everything else continues to work.
+
+This approach of programming enhances:
+
+- **Readability:** Developers can understand a piece of code without knowing the whole system.
+- **Maintainability:** Changing one part (like authentication) won’t break unrelated features.
+- **Testability:** Smaller, focused components are easier to test in isolation.
+- **Flexibility:** You can swap implementations (e.g., switch databases or auth providers) without rewriting the whole app.
+
+---
+
+## Separation of Concerns in NestJS
+
+One of the reasons developers love NestJS is that it **bakes Separation of Concerns into its architecture**. By default, NestJS applications are structured around three core building blocks: **modules, services, and controllers**. Each of these naturally maps to a specific concern.
+
+### 1. **Modules** → Group related functionality
+
+- A module acts like a **container** for a specific domain or feature.
+- Examples: `UsersModule`, `AuthModule`, `PostsModule`.
+- A module owns everything related to its concern and can expose services for other modules to use.
+
+Think of modules as **departments in a company** — each department specializes in one thing but can collaborate with others when needed.
+
+### 2. **Services** → Handle business logic
+
+- Services handle the actual “work” of the application.
+- Example: `UsersService` deals only with user data.
+- Example: `AuthService` deals only with authentication and tokens.
+- Services should **not depend on controllers** or contain HTTP logic.
+
+This makes them **reusable**. A service can be used in REST controllers, GraphQL resolvers, or even a CLI command without modification.
+
+### 3. **Controllers** → Handle HTTP requests
+
+- Controllers act as the **entry point** for requests.
+- Their job is to **receive a request, delegate the work to a service, and return a response**.
+- They should remain thin, containing no business logic.
+
+This ensures controllers are simple and services stay focused.
+
+---
+
+## Example: Auth and Users in NestJS
+
+Let’s look at a real-world scenario: Implementing **authentication**.
+
+### UserService in UsersModule
+
+```tsx
+@Injectable()
+export class UsersService {
+  constructor(private prisma: PrismaService) {}
+
+  findByEmail(email: string) {
+    return this.prisma.user.findUnique({ where: { email } });
+  }
+
+  create(data: any) {
+    return this.prisma.user.create({ data });
+  }
+}
+```
+
+UserService is only concerned with **managing user data**. It knows nothing about JWTs, passwords, or authentication.
+
+### AuthService in AuthModule
+
+```tsx
+@Injectable()
+export class AuthService {
+  constructor(
+    private usersService: UsersService,
+    private jwtService: JwtService,
+  ) {}
+
+  async validateUser(email: string, password: string) {
+    const user = await this.usersService.findByEmail(email);
+    // validate password...
+    return user;
+  }
+
+  login(user: any) {
+    return { access_token: this.jwtService.sign({ sub: user.id }) };
+  }
+}
+```
+
+AuthService handles **authentication logic**. It uses `UsersService`, to work with user data (findByEmail) but doesn’t leak authentication concerns back into it.
+A clear boundary is maintained: `UsersService` manages user data, `AuthService` manages auth.
+
+---
+
+## Conclusion
+
+Separation of Concerns isn’t just a design principle — it’s a mindset. By keeping each part of your application focused on a single responsibility, you reduce complexity, make testing easier, and keep your codebase flexible as your project grows.
+
+NestJS makes this natural with its **modules, services, and controllers**. If you embrace SoC from the start, you’ll end up with applications that are not only **scalable** but also a joy to maintain.
+
+(Proofread by ChatGPT)