Вопрос проверяет понимание архитектурных различий между Fastify и Express и умение оценивать реальную пользу от прироста производительности в веб-приложениях.
Fastify и Express решают одну задачу — обработку HTTP-запросов в Node.js, но делают это с разной внутренней архитектурой. Express появился в 2010 году и построен вокруг цепочки middleware: каждый запрос проходит через массив функций, а маршруты ищутся линейным перебором. Fastify создавался позже с прицелом на производительность: маршруты хранятся в radix tree, что даёт поиск за O(длину пути), а не O(число маршрутов).
const fastify = require('fastify')();
fastify.get('/user/:id', {
schema: {
params: { type: 'object', properties: { id: { type: 'integer' } } },
response: {
200: {
type: 'object',
properties: {
id: { type: 'integer' },
name: { type: 'string' }
}
}
}
}
}, async (req) => {
return { id: req.params.id, name: 'Alice', extra: 'ignored' };
});
fastify.listen({ port: 3000 });
В Express аналогичный код потребует ручной валидации и JSON.stringify, что медленнее и многословнее. Бенчмарки (например, от самого Fastify и независимые замеры) показывают разницу в 2–3 раза по RPS на простых эндпоинтах, но на реальных приложениях с БД разрыв сокращается до 10–30%.
В большинстве бизнес-приложений узким местом становится база данных, сеть или внешние сервисы, поэтому переход с Express на Fastify ради «скорости» без профилирования — преждевременная оптимизация. Однако Fastify даёт ещё и удобные схемы, плагины и TypeScript-типизацию, что делает его привлекательным и по причинам, не связанным с производительностью.
Итог: выбирайте Fastify, если у вас высокие требования к пропускной способности, строгая валидация и современный стек; Express остаётся разумным выбором для простых проектов и там, где важна огромная экосистема middleware.