Middleware

Почти каждому запросу к веб-приложению нужно одно и то же: прочитать тело, проверить, кто пришёл, записать событие в журнал, поймать исключение и вернуть понятную ошибку. Если вставлять эти проверки в каждый обработчик, код быстро превращается в копипасту. Middleware решает задачу иначе: общая логика выносится в отдельные функции, и фреймворк прогоняет запрос через них по очереди.

Такая схема есть почти везде: в Express и других фреймворках для Node.js, в Laravel и Symfony, в Django. В PHP-мире для неё даже есть общий стандарт PSR-15, чтобы прослойки из разных библиотек можно было сочетать.

Как выстраивается цепочка

Каждый слой получает запрос и решает одно из трёх: передать его дальше без изменений, дополнить (например, положить в запрос найденного пользователя) или прервать и сразу вернуть ответ. Порядок важен. Если логирование стоит после проверки доступа, отклонённые запросы в журнал не попадут. Если разбор тела стоит последним, проверка подписи не увидит данных.

Пример на Express

const express = require('express');
const app = express();

app.use(express.json());            // разбор JSON в теле
app.use((req, res, next) => {        // проверка ключа API
  if (req.get('X-Api-Key') !== process.env.API_KEY) {
    return res.status(401).json({ error: 'unauthorized' });
  }
  next();                            // передать дальше
});

app.get('/orders', (req, res) => res.json([]));

Обработчик /orders уже не думает о ключах: до него доходят только запросы, прошедшие аутентификацию. Достаточно забыть вызвать next(), и запрос «повиснет» без ответа — это самая частая ошибка новичков.

Второе значение термина

В корпоративной среде middleware — это ещё и промежуточное программное обеспечение между приложениями: брокеры сообщений, серверы приложений, шины интеграции. Они избавляют системы от необходимости знать друг о друге напрямую. В WordPress и Битриксе слова middleware нет, но похожую роль играют события и хуки: код подключается к обработке запроса, не трогая ядро.