Маршрутизация и middleware: что выполняется и в каком порядке

Security-ревью находит, что один админский эндпоинт принимает неаутентифицированные запросы. Auth-middleware существует, хорошо протестирован и применён — но зарегистрирован после этого маршрута. Обработчик сработал первым. Никто не написал баг; кто-то написал строки в неверном порядке.

Маршрутизация: сопоставление пути с обработчиком

Маршрутизация превращает POST /users/42/orders в один обработчик плюс извлечённые параметры (userId=42). Способ сопоставления определяет её стоимость:

• Линейный перебор — пробовать каждый маршрут по порядку. Просто, но O(n) по числу маршрутов; нормально для десятков.
• Radix-trie (httprouter, Echo, find-my-way у Fastify) — префиксное дерево по сегментам пути. O(длины пути), независимо от числа маршрутов, поэтому 10 и 10 000 маршрутов сопоставляются за одно время.

На практике маршрутизация — это микросекунды в любом случае; она почти не доминирует в задержке. Настоящие баги маршрутизации — это корректность: пересекающиеся шаблоны (/users/:id и /users/me), несовпадение по завершающему слешу и путаница методов (GET-маршрут перекрывает POST на том же пути).

Middleware: цепочка вокруг обработчика

Middleware — функции, которые выполняются до и/или после обработчика, каждая может прочитать запрос, изменить его, прервать или передать управление дальше. Они обслуживают сквозные задачи (cross-cutting concerns) — то, что нужно каждому эндпоинту, но что ни один не должен реализовывать заново: аутентификация, логирование, парсинг тела, rate limiting, сжатие, обработка ошибок.

Модель — луковица. Запрос идёт внутрь через каждый слой к обработчику, затем ответ идёт наружу через те же слои в обратном порядке:

запрос  →  logging → auth → bodyParser → handler
ответ   ← logging ← auth ← bodyParser ← handler

Слой, вызывающий next(), передаёт управление внутрь. Слой, который отвечает без вызова next(), прерывает цепочку (short-circuit) — обработчик не выполняется. Именно так rate limiter возвращает 429, а auth-слой возвращает 401 до запуска бизнес-логики.

Порядок — это граница безопасности

Поскольку каждый слой может прервать цепочку, порядок регистрации решает, что реально защищает обработчик:

Правило, предотвращающее все пять: дешёвые и защитные слои идут первыми (лимиты размера, rate limit, auth), дорогие и опциональные — последними (парсинг тела, сжатие), а обработчик ошибок — самым внешним, чтобы охватывать всё.

Куда реально уходит время

Middleware — ещё и место, где копится невидимая задержка. Каждый слой выполняется на каждом запросе. Парсер тела, разбирающий 1 МБ JSON, слой логирования с синхронным DNS-запросом, auth-слой, дёргающий удалённый сервис токенов без кеша — всё это добавляет миллисекунды к каждому запросу, а не только к медленным. Профилировать медленный эндпоинт — значит замерять цепочку, а не только обработчик.