NestJS — від абстракцій до інструмента

Кілька місяців тому я скептично ставився до NestJS. Фреймворк здавалося простою обгорткою над Express або Fastify, з безліччю абстракцій, які більше ускладнюють життя, ніж спрощують. Але з часом моя думка змінилася. І ось мій шлях.

Плюси, які зазвичай виділяють:

• Dependency Injection (DI) — для когось мастхев, але часто виглядає як «зайве» у невеликих проєктах.
• Сувора структура проєкту — комусь подобається, але розкласти папки я можу й без фреймворку.
• Типізація — працює добре, але те ж саме дають Fastify, Elysia, Hono.

Що викликало сумніви:

• «Магія» під капотом. Nest — це набір абстракцій над Express/Fastify, і ця магія іноді важко піддається дебагу.

• Забув додати сервіс в providers? Не працює. Не імпортував модуль? Тиша.
• Поріг входу. З Nest доводиться вчити окрему модель: RxJS, декоратори, життєвий цикл, пайпи, інтерсептори, гуарди.
  На відміну від Express, Fastify, Koa чи Hono, де API на 70–80% схожі, NestJS — це окрема «парадигма».

Що змінило мій погляд:

Після глибшої роботи з NestJS я відкрив для себе реально потужну реалізацію мікросервісної архітектури.

NestJS дає:

• Простий запуск мікросервісів.
• Гнучкий вибір транспорту: TCP, Redis, RabbitMQ, NATS, Kafka тощо.
• Можливість легко переключатися між брокерами без зміни бізнес-логіки.

Особливо приємно, що можна стартувати на TCP (мінімальний overhead), а потім — мігрувати на Rabbit чи Kafka майже без змін у коді.
Схожу зручність я бачив тільки у Moleculer.

Висновок

NestJS — не просто фреймворк з «абстракціями заради абстракцій». Він має свої складнощі, але й потужні можливості. Особливо якщо мова йде про мікросервіси — тут він справді розкривається.

Цей текст взято з особистого блогу після отримання дозволу автора.