تا همین چند ماه پیش، خیلی از تیمها NestJS را فقط به عنوان یک فریم ورک مرتب برای نوشتن API می دیدند. ماژول ها، Dependency Injection و دکوراتورها کار را تمیز نگه می داشتند، اما وقتی سرویس وارد Kubernetes می شد، همچنان با همان دردسرهای قدیمی رو به رو بودند: لاگ های پراکنده، health check ناقص، و خاموش شدن ناگهانی podها هنگام deploy.
اولین تغییر مهم: Observability دیگر اختیاری نیست.
NestJS حالا SDK رسمی nestjs/observ@ را دارد. برخلاف ابزارهای عمومی که باید خودتان span و metric تعریف کنید، این SDK مستقیماً به lifecycle فریم ورک وصل میشود. درخواستهای HTTP، GraphQL، gRPC و حتی میکروسرویس ها به صورت خودکار trace می شوند. وقتی یک request کند می شود، دیگر لازم نیست بین ده تا لاگ مختلف بگردید؛ waterfall کامل را می بینید.
برای تیم هایی که چند سرویس NestJS دارند، این یعنی correlation واقعی بین سرویس ها بدون اینکه مجبور باشید هر بار OpenTelemetry را از صفر تنظیم کنید.
اولین تغییر مهم: Observability دیگر اختیاری نیست.
NestJS حالا SDK رسمی nestjs/observe@ را دارد. برخلاف ابزارهای عمومی که باید خودتان span و metric تعریف کنید، این SDK مستقیماً به lifecycle فریم ورک وصل می شود. درخواست های HTTP، GraphQL، gRPC و حتی میکروسرویس ها به صورت خودکار trace میشوند. وقتی یک request کند می شود، دیگر لازم نیست بین ده تا لاگ مختلف بگردید؛ waterfall کامل را می بینید.
برای تیم هایی که چند سرویس NestJS دارند، این یعنی correlation واقعی بین سرویس ها بدون اینکه مجبور باشید هر بار OpenTelemetry را از صفر تنظیم کنید.
سومین موضوعی که کمتر دربارهاش حرف زده میشود: Graceful Shutdown واقعی.
NestJS همیشه enableShutdownHooks داشت، اما در نسخه ۱۲ و با ترکیب بهتر با Fastify و Express، رفتار shutdown قابلپیشبینیتر شده است. وقتی Kubernetes یک pod را terminate میکند، سرویس فرصت دارد:
درخواست های در حال اجرا را تمام کند.
connectionهای دیتابیس و queue را ببندد.
و تازه بعد از آن process را kill کند.
اگر هنوز در Dockerfile یا deployment خودتان SIGTERM را درست handle نمیکنید، الان بهترین زمان برای اصلاح آن است. یک health check ناقص + shutdown ضعیف هنوز هم یکی از رایج ترین دلایل ۵۰۲ و connection reset در زمان deploy است.
نکته عملی برای تیمهای: DevOps.
اگر میخواهید از نسخه ۱۲ بیشترین بهره را ببرید، این سه کار را در اولویت بگذارید:
nestjs/observe@ را حداقل در staging فعال کنید و یک dashboard ساده برای latency و error rate بسازید.
Validation را به Standard Schema منتقل کنید (حتی اگر فقط برای endpointهای جدید).
Graceful shutdown و readiness/liveness probe را با هم تست کنید؛ نه جداگانه.
NestJS دیگر فقط یک فریم ورک مرتب نیست. نسخه های اخیر آن نشان می دهد که تیم سازنده واقعاً به دردسرهای production فکر می کند. اگر هنوز با تنظیمات نسخه ۱۱ و tooling قدیمی کار می کنید، احتمالاً دارید بخشی از مزیت های جدید را از دست می دهید.