Что такое Middleware

Middleware это код, который стоит в середине пайплайна. Он получает управление не потому, что компонент или контроллер вызвал его напрямую. Он получает управление потому, что фреймворк или библиотека встроили его в цепочку обработки.

Простая формула для ответа:

Middleware находится между входом и конечным обработчиком. Он может выполнить общую проверку, изменить данные, завершить обработку раньше или передать управление дальше.

Для frontend-кандидата важно не застрять в одном примере. Если вопрос общий, сначала скажите про паттерн, а потом добавьте 2-3 контекста: HTTP middleware на сервере, Redux middleware для actions, Next.js middleware на уровне маршрутов, interceptor в HTTP-клиенте как похожий по смыслу слой.

В HTTP-сценарии middleware обычно стоит до route handler или контроллера. Например, он может проверить cookie, токен, язык, лимит запросов или права доступа. Если все хорошо, запрос идет дальше. Если нет, middleware возвращает ответ сам, например 401, 403 или redirect.

В state-management сценарии middleware может перехватить action до reducer. Это удобно для логирования, аналитики, async-операций и нормализации ошибок. Но reducer все равно должен оставаться предсказуемым, а middleware не должен тайно менять смысл каждого action. Если middleware скрывает ошибку или подменяет payload, UI может показать старые данные, не выйти из loading или отправить неверную аналитику.

Пример не нужно зубрить. Он нужен, чтобы показать место middleware в цепочке.

const loggerMiddleware = (store) => (next) => (action) => {
  console.log("action", action.type);

  return next(action);
};

Здесь action еще не дошел до reducer. Middleware может залогировать его и вызвать next(action), чтобы передать действие дальше. Если забыть return next(action), action может не дойти до reducer, UI не обновится, а баг будет выглядеть так, будто компонент или reducer не работает. Безопасная привычка: ранний возврат делать только намеренно, например для отмены action с понятной причиной, и покрывать это тестом.

Если вопрос задан на frontend-интервью, можно аккуратно упомянуть Next.js или BFF. Там middleware часто используют для ранних решений: проверить авторизацию, выбрать locale, сделать redirect, добавить заголовки, ограничить доступ к маршруту.

Важно сказать про ограничение. Такой код находится на горячем пути навигации или запроса. Если в него положить тяжелую бизнес-логику, лишние сетевые запросы или сложный парсинг, пользователь получит более медленный переход, а ошибки станут сложнее отлаживать. Безопаснее принимать простые решения по уже доступным cookie, URL и заголовкам, а данные для экрана загружать там, где UI может показать loading, error и retry.

Хороший middleware решает сквозную задачу. Например: auth, rate limit, CORS, CSRF, логирование, трассировка, locale, нормализация ошибок API. Плохой middleware начинает решать частный сценарий экрана: какую кнопку показать, как валидировать конкретную форму, какой текст вывести в модальном окне. Еще один плохой признак: middleware делает запрос за данными для компонента, но не дает компоненту управлять отменой запроса, race condition и состоянием ошибки.

На интервью это можно сформулировать так:

Я бы держал в middleware только правила, которые одинаково применяются к группе запросов, маршрутов или actions. Если логика зависит от конкретной фичи, лучше оставить ее в feature-слое, чтобы поведение было явным и тестируемым.

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

Если хотите звучать сильнее, добавьте риск: "Я бы не складывал туда всю бизнес-логику, потому что она станет неявной. Для frontend это может привести к неожиданным редиректам, потерянным actions, лишним запросам и сложной отладке".