NestJS проти Node.js: Чому при великих масштабах структура переважає над свободою.

Поетапне обґрунтування: чому нам потрібен NestJS

Архітектурна еволюція JavaScript з боку сервера

JavaScript спочатку був просто мовою скриптів для додавання невеликої кількості інтерактивності до веб-сторінок. З часом він перетворився на серйозну технологію, здатну працювати в якості основи для цілих систем бекенду. Node.js відіграв ключову роль у цьому переході, адже дозволив писати логіку з боку сервера за допомогою тієї ж мови, яку розробники вже використовували в браузері.

Однак у міру того, як додатки ставали все більшими за розміром та складнішими, команди почали стикатися з проблемами у організації коду, масштабованості та довгостроковому підтримуванні. Node.js забезпечує необхідне середовище для виконання JavaScript поза браузером, але навмисно не вказує, як саме слід проектувати додаток. Така відкритість є зручною, але у великих проектах це часто призводить до того, що кодові бази розростаються в різних напрямках та стають важкими для підтримки.

NestJS виник як рішення саме цієї проблеми. Він базується на Node.js та використовує чітко визначену архітектуру, послідовну організацію проєктів, вставку залежностей та усталені шаблони проектування, що всі разом спрямовані на допомогу командам у створенні масштабованого та підтримуваного програмного забезпечення на рівні корпорацій. NestJS не є заміною Node.js — це спосіб формування та регламентації процесу створення та підтримки додатків на основі Node.js.

У цій статті поетапно та простою мовою розглядається логіка вибору архітектурної рамки з чіткими принципами, а також те, що цей вибір означає для команди з більш широкої інженерної точки зору.

Основна відмінність — середовища виконання проти рамок з чіткими принципами: двигун проти автомобіля

Корисний спосіб зрозуміти взаємозв’язок між Node.js та NestJS — це порівняти двигун із готовим автомобілем. Обидва працюють на різних рівнях, обидва є необхідними, але вирішують різні проблеми.

• Node.js (двигун): середовище виконання, яке дозволяє JavaScript працювати на сервері, а не у вкладці браузера. Воно ефективне у одночасному виконанні багатьох операцій, але надає повністю вільний простір без жодних вбудованих правил щодо структури вашого коду.
• NestJS (автомобіль): фреймворк, побудований на основі цього середовища виконання. Він надає структурований, передбачуваний план для створення більших додатків. Він не конкурує з Node.js — він інтегрується з ним, щоб код залишався організованим та керованим у міру його розробки.

The Express.js Middle Ground and "Architectural Chaos"

Багато розробників обирають Express.js як легший інструмент для роботи з прямим обробленням запитів у Node.js, оскільки це мінімалістичний та гнучкий набір інструментів для веб-запитів.

• Його сильна сторона: Express майже не накладає жодних правил, що дозволяє дуже швидко створювати невеликі проекти та прототипи.
• Його слабка сторона: саме ця свобода перетворюється на проблему, коли проект чи команда ростуть. Без спільної структури код схильний до заплутаності, несуворості, складності у тестуванні та загалом утруднює підтримку.

NestJS вирішує цю проблему, вбудовуючи з самого початку проекту чітко визначену структуру та набір конвенцій.

Щоб вирішити проблеми, які виникають під час масштабування додатку, NestJS активно запозичив ідеї з фронтенд-фреймворку Angular та впровадив їх у світ бекенду Node.js.

Перехід від фреймворку без чітких правил або від мінімалістичного фреймворку на кшталт Express до повністю структурованого фреймворку обумовлений кількома конкретними інженерними проблемами. Наведені нижче моменти детально пояснюють, чому команди обирають NestJS замість простого Node.js або Express.

Пункт 1: Спільні конвенції замінюють інформальні правила

У слабко структурованих середовищах, таких як Express, організація кодової бази зазвичай залежить від інформальних правил та звичок, які повністю розуміють лише їхні творці. Нові інженери, які приєднуються до такого проекту, можуть витрачати тижні лише на те, щоб з’ясувати, де знаходяться певні елементи та як вони взаємодіють між собою.

NestJS уникає цього, дотримуючись принципу «звичай перед конфігурацією»:

• Заздалегідь визначена структура: кожний проект NestJS починається з однаково чітко визначеного шаблону.
• Миттєва знайомість: оскільки всі додатки NestJS мають однакову архітектурну структуру, розробник, який переходить від одного проекту до іншого, може майже миттєво орієнтуватися.
• Швидше адаптування: команди витрачають значно менше часу на пояснення новим співробітникам індивідуальних налаштувань та більше часу на реальну реалізацію функцій.

Пункт 2: Вбудована підтримка TypeScript запобігає дорогим помилкам

Звичайний Node.js працює на JavaScript — мові, яка виявляє помилки, пов’язані з даними, лише тоді, коли код фактично виконується. Навіть незначна опечатка може призвести до зупинки роботи продакшн-системи.

NestJS вирішує цю проблему, роблячи TypeScript частиною самої фреймворк-архітектури першого класу:

• Раннє виявлення помилок: TypeScript діє як розумний коректор, вказуючи на помилки під час написання коду, а не після його розгортання.
• на відміну від ситуації, коли додавання TypeScript до проекту Express є незграбним та лише частково ефективним, NestJS застосовує його послідовно у кожній частині додатку.
• Приблизно на 70% менше багів: виявлення помилок, пов’язаних із типами, під час розробки дозволяє усунути до 70% проблем під час роботи додатку, які інакше потрапили б до кінцевих користувачів.

const userService = new UserService();

constructor(private userService: UserService) {}