В каких backend-проектах Fastify является сильным выбором, а где лучше выбрать более простой или другой стек?

Когда Fastify — сильный выбор

Fastify оптимален там, где важна пропускная способность, строгость типов и предсказуемая архитектура. Конкретные сценарии:

• API-сервисы с высокой нагрузкой — JSON-сериализация через fast-json-stringify работает в 2-5x быстрее стандартного JSON.stringify; валидация через ajv выполняется на этапе компиляции схемы.
• Микросервисы и BFF — модель плагинов и scope позволяет строго разграничить домены без внешнего DI-контейнера.
• TypeScript-проекты — встроенные типы и типизация через RouteGenericInterface, FastifyRequest<{Body: T}> обеспечивают end-to-end type safety без дополнительных инструментов.
• Serverless с холодным стартом — минимальный overhead при инициализации делает Fastify быстрее Express и Koa в AWS Lambda / Cloudflare Workers.
• Команды, привыкшие к конвенциям — plugin-based архитектура задаёт единый способ добавления функциональности, что снижает разброс подходов в команде.

Когда лучше выбрать другой стек

• Прототипирование и MVP за один день — Express с набором готовых middleware (body-parser, morgan, cors) запускается с нуля быстрее. Экосистема Express-плагинов огромна, и гуглить ошибки проще.
• Full-stack с SSR — если нужен рендеринг шаблонов, лучше взять Nuxt/Next на фронте, а не добавлять Handlebars к Fastify.
• Monolith с глубокой ORM-интеграцией — NestJS + TypeORM / Prisma даёт декораторный стиль, встроенный DI и CLI для генерации кода, что ускоряет работу в большой команде.
• Команда без опыта Node.js — если backend-разработчики знают Python, лучше взять FastAPI; если Go — Gin или Echo. Fastify не компенсирует незнакомый язык.
• Реал-тайм приложения с WebSocket-heavy логикой — Fastify поддерживает WebSocket через @fastify/websocket, но если 90% функционала — это WS, рассмотрите Socket.io или uWebSockets.js.

Практический пример: минимальный JSON API

import Fastify from 'fastify';

const app = Fastify({ logger: true });

const schema = {
  body: {
    type: 'object',
    required: ['name'],
    properties: { name: { type: 'string', minLength: 2 } },
  },
  response: {
    201: {
      type: 'object',
      properties: { id: { type: 'string' }, name: { type: 'string' } },
    },
  },
};

app.post('/users', { schema }, async (req, reply) => {
  const user = await db.create(req.body);
  return reply.status(201).send(user);
});

await app.listen({ port: 3000 });

Подводные камни

• Fastify не подходит для проектов, где нет культуры schema-first разработки — без схем теряется половина ценности фреймворка (быстрая сериализация и валидация).
• Экосистема официальных плагинов (@fastify/*) меньше, чем у Express — некоторые задачи потребуют написания собственного плагина или адаптации Express-middleware через @fastify/express.
• Документация по миграции между мажорными версиями (v3 → v4 → v5) требует внимания: API async/await хуков менялся, и старые туториалы могут вводить в заблуждение.
• Если команда привыкла к middleware-цепочке Express, модель хуков Fastify (onRequest, preParsing, preValidation, preHandler, preSerialization, onSend) поначалу кажется избыточной.
• Для очень маленьких скриптов (<100 строк) накладные расходы на настройку плагинов и схем не оправданы — лучше использовать голый http или polka.
• В Serverless-среде с долгим cold start из-за большого числа плагинов нужно профилировать время инициализации через fastify --log-level=debug и lazy-loading плагинов.

• Выбирать Fastify по популярности, а не по требованиям проекта
• Игнорировать опыт команды, эксплуатацию и стоимость поддержки
• Не называть ситуации, где Fastify будет плохим выбором

• Называет критерии выбора Fastify
• Учитывает команду, эксплуатацию, стоимость и риски
• Может назвать сценарии, где выбрал бы альтернативу