Пошук уроків, статей та іншого контенту
У якому порядку насправді виконуються Middleware, Guards, Interceptors, Pipes і Exception Filters.
Кожен з розглянутих у цьому курсі механізмів (Guards, Pipes, Interceptors, Exception Filters) виконується на своєму, фіксованому місці в обробці одного запиту — розуміння повної послідовності допомагає передбачити, де саме перехопити чи змінити поведінку, і чому, наприклад, Guard не може покладатись на дані, які Pipe ще не встиг підготувати.
Middleware — виконується найпершим, ще до визначення того, який саме контролер оброблятиме запит (концептуально схоже на middleware.ts у Next.js, курс Next.js, хоча механізм інший).
Guards — перевіряють, чи дозволено запиту продовжитись (автентифікація/авторизація).
Interceptors (частина «до») — код, виконаний перед методом контролера.
Pipes — валідація й трансформація параметрів запиту.
Controller handler — власне метод контролера, що делегує роботу сервісу.
Interceptors (частина «після») — код, виконаний після отримання результату, може трансформувати відповідь.
Exception Filters — перехоплюють будь-який виняток, кинутий на будь-якому з попередніх кроків, і формують відповідь про помилку.
Запит → Middleware → Guards → Interceptors(до) → Pipes → Controller → Interceptors(після) → Відповідь
↓
Exception Filter (перехоплює виняток з будь-якого кроку)Guard виконується до Pipes — тому Guard не може покладатись на вже провалідовані й трансформовані дані тіла запиту, лише на сирі дані запиту (заголовки, токен). Це й логічно: перевірка «чи можна взагалі обробляти цей запит» має сенс раніше за перевірку «чи коректний формат даних усередині запиту», яка не потрібна взагалі, якщо запит однаково буде відхилено на етапі авторизації.
Ця сама ідея пронизаного через увесь запит конвеєра обробки — не унікальна для NestJS: Next.js має власний, інакше влаштований конвеєр (middleware → Server Component рендеринг → Server Action), а Express — послідовність middleware-функцій. Кожен фреймворк по-своєму реалізує ту саму загальну ідею — розбити обробку запиту на послідовні, композовані шари відповідальності.
Розуміння цього порядку допомагає свідомо обирати, куди саме класти нову логіку: перевірка прав доступу — у Guard, не в контролері; валідація формату вхідних даних — у Pipe, не вручну в сервісі; логування чи трансформація відповіді для всього застосунку — в Interceptor, не дублюванням у кожному контролері; обробка й форматування помилок — в Exception Filter, централізовано.
Класти перевірку авторизації в Pipe замість Guard — Pipe виконується пізніше, тож частина роботи (валідація даних запиту, який однаково буде відхилено) виконується даремно.
Очікувати, що Interceptor «до»-частина побачить уже провалідовані Pipe дані — порядок конвеєра означає, що Interceptor обгортає виклик контролера і Pipes разом, а не лише сам контролер.
Не усвідомлювати, що Exception Filter — єдине місце конвеєра, здатне перехопити помилку з будь-якого попереднього кроку (Guard, Pipe, сам контролер, Interceptor) в одному місці.
Один HTTP-запит у NestJS проходить фіксовану послідовність: Middleware → Guards → Interceptors (до) → Pipes → Controller → Interceptors (після) → відповідь, з Exception Filter, здатним перехопити виняток на будь-якому з цих кроків. Розуміння цього порядку — не формальність, а практичний інструмент: він підказує, у якому саме механізмі має жити конкретна логіка (авторизація, валідація, логування, обробка помилок), щоб застосунок лишався структурованим і передбачуваним на масштабі.