Express против Fastify: middleware и пропускная способность

Две философии: цепочка vs инкапсулированное дерево плагинов

Прежде чем выбирать фреймворк, ответь на один вопрос: нужна ли тебе максимально широкая экосистема с простейшей моделью, или встроенная schema-валидация и сериализация? Ответ, как правило, и решает выбор. Express намеренно мал: запрос течёт через линейную цепочку middleware, каждый из которых — функция (req, res, next), мутирующая req/res и вызывающая next(), чтобы передать управление дальше, или next(err), чтобы прыгнуть в обработчик ошибок. В него почти не вшито мнений — ты собираешь роутинг, парсинг тела, авторизацию и логирование из обширной экосистемы app.use()-middleware. Этот минимализм — его суперсила: крупнейший каталог middleware в мире Node, десятилетие боевой обкатки и сигнатура, которую уже знает каждый Node-разработчик.

import express from "express";
const app = express();

// глобальный middleware: бежит на каждый запрос, в порядке регистрации
app.use(express.json());
app.use((req, res, next) => { req.startedAt = Date.now(); next(); });

app.get("/users/:id", (req, res) => {
  res.json({ id: req.params.id });
});

Fastify ставит на другое: запрос проходит через хуки жизненного цикла (onRequest, preParsing, preValidation, preHandler, …), а роуты группируются в плагины, зарегистрированные через fastify.register(). Определяющая черта — инкапсуляция: плагин получает собственную область, поэтому декораторы, хуки и middleware, зарегистрированные внутри него, не протекают к соседям. Это фича для модульности, но она удивляет беженцев из Express, ожидающих, что app.use() глобален всюду.

import Fastify from "fastify";
const app = Fastify({ logger: true }); // pino встроен

await app.register(async (instance) => {
  // этот хук бежит только для роутов внутри области этого плагина
  instance.addHook("preHandler", async (req) => { req.startedAt = Date.now(); });
  instance.get("/users/:id", async (req) => ({ id: req.params.id }));
});

Настоящий разделитель: schema-driven валидация и сериализация

У Express нет встроенной истории валидации или сериализации — ты тянешь zod, joi или express-validator, а сериализуешь через res.json(), который вызывает JSON.stringify. Fastify встраивает и то и другое в определение роута через JSON Schema. Схема запроса валидирует и приводит входящие params/query/body до того, как выполнится обработчик. Схема ответа — это рычаг throughput: fast-json-stringify компилирует из этой схемы специализированную функцию-сериализатор заранее, так что она никогда не обходит объект неизвестной формы в рантайме, как вынужден делать обобщённый JSON.stringify.

app.get("/users/:id", {
  schema: {
    params: { type: "object", properties: { id: { type: "string" } } },
    response: {
      200: {
        type: "object",
        properties: { id: { type: "string" }, name: { type: "string" } },
      },
    },
  },
}, async (req) => getUser(req.params.id));

Этот скомпилированный сериализатор — самый релевантный для реального мира выигрыш, потому что он ускоряет каждый ответ, а не только синтетический пустой роут, — и в качестве бонуса поля, которых нет в схеме ответа, вырезаются, так что ты не можешь случайно утечь passwordHash.

Ловушка async-ошибок Express 4

Самый острый режим сбоя историчен и до сих пор всюду. Express 4 не ловит зареджекченные промисы из async-обработчиков роутов. Если async-обработчик бросает (или await-ит что-то, что реджектится), у Express 4 нет await вокруг твоей функции, так что reject становится unhandledRejection — который с Node 15 по умолчанию роняет процесс — вместо того, чтобы дойти до твоего middleware обработки ошибок.

// Express 4 — СЛОМАНО: reject ускользает в unhandledRejection
app.get("/u/:id", async (req, res) => {
  const user = await db.find(req.params.id); // если это реджектнется…
  res.json(user);                            // …Express 4 никогда не поймает
});

// Express 4 — ФИКС: try/catch + next или обёртка вроде express-async-errors
app.get("/u/:id", async (req, res, next) => {
  try { res.json(await db.find(req.params.id)); }
  catch (err) { next(err); } // передать в middleware ошибок
});

Express 5 (уже релизнут) это чинит: зареджекченные промисы из async-обработчиков автоматически форвардятся в обработчик ошибок, закрывая дыру. У Fastify этой проблемы не было никогда — обработчики async по дизайну, их reject await-ятся и роутятся в хук setErrorHandler. Если ты на Express 4, оборачивай каждый async-обработчик (или прими express-async-errors); тихое падение — самый частый production-баг в старых Express-приложениях.