فریمورک بک اند NestJS چیه و چرا به جای API route های Next.js باید بهش فکر کنی؟

یه الگوی خیلی رایج توی پروژه‌های Next.js اینه که backend رو هم همون‌جا، توی پوشه‌ی app/api یا pages/api، پیاده می‌کنن. برای یه پروژه‌ی کوچیک یا یه MVP این کار کاملاً منطقیه — چرا یه سرور جدا راه بندازی وقتی همون فریم‌ورک فرانت‌اند می‌تونه چند تا endpoint هم سرو کنه؟ ولی وقتی پروژه بزرگ‌تر میشه، وقتی تعداد endpoint ها از چند تا به چند ده تا میرسه، وقتی نیاز به background job و queue و اتصال به چند تا سرویس خارجی پیدا می‌کنی، همون سادگی اولیه تبدیل به یه مشکل میشه. اینجاست که NestJS وارد بازی میشه.

NestJS دقیقاً چیه؟

NestJS یه فریم‌ورک backend برای Node.js هست که روی TypeScript ساخته شده (هرچند جاوااسکریپت خالص هم پشتیبانی میشه) و زیرش از Express یا Fastify به‌عنوان HTTP server استفاده می‌کنه — خودت انتخاب می‌کنی کدومو بخوای. تفاوت اصلیش با یه فریم‌ورک minimal مثل Express اینه که NestJS یه معماری کامل و opinionated روی سرت میذاره: ماژول‌ها، کنترلرها، provider ها (سرویس‌ها)، و یه سیستم dependency injection که کل این‌ها رو به هم وصل می‌کنه.

یه مثال ساده از یه ماژول در NestJS این شکلیه:

// users.controller.ts
import { Controller, Get, Post, Body, Param } from '@nestjs/common';
import { UsersService } from './users.service';

@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Get(':id')
  findOne(@Param('id') id: string) {
    return this.usersService.findOne(id);
  }

  @Post()
  create(@Body() createUserDto: CreateUserDto) {
    return this.usersService.create(createUserDto);
  }
}

// users.service.ts
import { Injectable } from '@nestjs/common';

@Injectable()
export class UsersService {
  private users = [];

  findOne(id: string) {
    return this.users.find((u) => u.id === id);
  }

  create(data: CreateUserDto) {
    const user = { id: Date.now().toString(), ...data };
    this.users.push(user);
    return user;
  }
}

اینجا UsersController مسئول گرفتن request هست، و منطق واقعی رفته توی UsersService. نکته‌ی مهم اینه که کنترلر اصلاً نمی‌دونه UsersService چطور ساخته میشه — فقط توی constructor خواستتش، و خود NestJS با سیستم DI اون رو براش می‌سازه و تزریق می‌کنه. این جدایی وقتی پروژه بزرگ میشه، فرق بین یه کدبیس قابل نگهداری و یه فایل ۲۰۰۰ خطی که همه ازش می‌ترسن رو می‌سازه.

چرا به‌جای API route های Next.js؟

API route های Next.js برای یه سری کار خیلی خوب هستن: یه webhook ساده، یه پراکسی کوچیک به یه سرویس دیگه، یا چند تا endpoint که مستقیم به دیتای همون صفحه مربوط میشن. مشکل از جایی شروع میشه که بخوای این API route ها رو به یه backend واقعی تبدیل کنی.

اول از همه، API route ها ساختار معماری ندارن. هیچ الگوی رسمی‌ای برای جدا کردن business logic از لایه‌ی HTTP وجود نداره؛ هر تیمی به روش خودش فایل‌ها رو می‌چینه، و این یعنی هر پروژه‌ی Next.js با بک‌اند بزرگ، یه معماری دست‌ساز و غیر استاندارد داره که فقط خود همون تیم باهاش راحته.

دوم، هیچ dependency injection ای وجود نداره. اگه بخوای یه سرویس دیتابیس رو mock کنی برای تست، یا بخوای پیکربندی مختلف برای محیط‌های مختلف (dev/staging/production) داشته باشی، باید خودت از صفر این infrastructure رو بسازی — چیزی که توی NestJS از روز اول رایگان همراهته.

سوم، قابلیت‌های آماده‌ای مثل guard (برای authorization)، pipe (برای validation و transform کردن ورودی)، interceptor (برای لاگ‌گیری یا caching)، و پشتیبانی built-in از microservices، WebSocket، GraphQL و message queue هایی مثل RabbitMQ و Kafka، همه بخشی از خود فریم‌ورک هستن. توی Next.js API route ها، همه‌ی این‌ها رو باید دستی یا با کتابخونه‌های جداگانه پیاده کنی و خودت به هم وصلشون کنی.

و در آخر، مسئله‌ی جدایی نگرانی‌هاست (separation of concerns). وقتی frontend و backend توی یه codebase و یه پروسه‌ی deploy قاطی میشن، اسکیل کردنشون هم مستقل از هم غیرممکن میشه. اگه backendت نیاز به منابع محاسباتی بیشتری داره ولی frontendت نه، توی Next.js نمی‌تونی این دو تا رو جدا اسکیل کنی؛ ولی وقتی backend یه سرویس مجزای NestJS باشه، این کار پیش‌فرضه.

این به این معنی نیست که Next.js API route ها همیشه اشتباهن. برای پروژه‌های کوچیک، یا وقتی backend واقعاً فقط چند تا وظیفه‌ی ساده داره، اضافه کردن یه فریم‌ورک جدا مثل NestJS ممکنه بیش از حد باشه. سؤال واقعی اینه: آیا backendت قراره رشد کنه و پیچیده بشه، یا همیشه همین‌قدر کوچیک می‌مونه؟

مقایسه با بقیه‌ی فریم‌ورک‌ها

Express پایه و اساس خیلی از فریم‌ورک‌های Node.js از جمله خود NestJS هست. مزیتش انعطاف‌پذیری مطلقشه — هیچ ساختاری بهت تحمیل نمی‌کنه. اما همین انعطاف، مشکل هم هست: توی یه تیم بزرگ، هر توسعه‌دهنده ممکنه یه روش متفاوت برای سازمان‌دهی کد انتخاب کنه، و بعد از یه مدت کدبیس به یه مجموعه‌ی ناهماهنگ از الگوهای مختلف تبدیل میشه. NestJS اساساً یه لایه‌ی معماری روی همین Express (یا Fastify) میذاره تا این مشکل حل بشه.

Fastify به تنهایی روی سرعت و performance تمرکز داره و از Express سریع‌تره، ولی از نظر فلسفه شبیه Expressه: یه فریم‌ورک minimal، نه یه معماری کامل. جالبه که NestJS می‌تونه از Fastify هم به‌عنوان HTTP adapter استفاده کنه، یعنی می‌تونی هم ساختار NestJS رو داشته باشی هم سرعت Fastify رو.

Next.js API routes، همون‌طور که گفتیم، برای کارهای سبک عالیه ولی برای یه backend کامل و مستقل طراحی نشده؛ اساساً بخشی از یه فریم‌ورک فرانت‌اند هست، نه یه فریم‌ورک backend.

اگه بخوای NestJS رو با دنیای بیرون از Node.js مقایسه کنی، شباهت مفهومیش به Spring Boot توی جاوا یا Laravel توی PHP بیشتره تا به Express — همه‌ی این‌ها فریم‌ورک‌های opinionated و کامل هستن که یه معماری استاندارد و ابزارهای آماده برای dependency injection، validation، و routing ارائه میدن. اگه از پیشینه‌ی جاوا یا PHP وارد دنیای Node شده باشی، NestJS احتمالاً برات خیلی آشنا به نظر میاد.

چه زمانی سراغ NestJS نریم؟

اگه پروژه‌ت واقعاً کوچیکه، یا داری یه prototype سریع می‌سازی، یا تیمت با معماری‌های سنگین راحت نیست، NestJS ممکنه سربار غیرضروری اضافه کنه. یادگیریش هم نسبت به یه Express ساده زمان بیشتری می‌بره، چون باید با مفاهیمی مثل ماژول، decorator، و DI آشنا بشی. برای یه API با پنج تا endpoint که قرار نیست رشد کنه، یه Express ساده یا همون API route های Next.js احتمالاً کافیه.

جمع‌بندی

انتخاب بین NestJS و API route های Next.js در نهایت به اندازه و آینده‌ی پروژه‌ت برمی‌گرده. اگه داری یه backend می‌سازی که قراره چند تا سرویس، چند تا تیم، و منطق پیچیده‌ی business رو در خودش جا بده، NestJS یه پایه‌ی معماری محکم بهت میده که از اول جلوی خیلی از مشکلات ساختاری رو می‌گیره. اگه فقط چند تا endpoint کنار یه اپلیکیشن فرانت‌اند نیاز داری، همون API route های Next.js بدون هیچ overhead ای کارتو راه می‌ندازه. مشکل از جایی شروع میشه که یه پروژه‌ی «فقط چند تا endpoint» رو با فرض «همیشه همین‌قدر کوچیک می‌مونه» شروع کنی و بعد از یه سال متوجه بشی داری یه backend کامل رو توی یه پوشه‌ی api مدیریت می‌کنی.