Hono vs Fastify vs Express для лёгких TypeScript API

Почему этот выбор кажется сложнее, чем должен быть

Hono, Fastify и Express могут успешно запустить небольшой API. Именно поэтому выбор и раздражает. Вы не отбрасываете плохие варианты. Вы выбираете компромисс, который будет меньше всего мешать вам через шесть недель.

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

Каждый фреймворк подталкивает к своему стилю работы. Express даёт знакомый и свободный подход. Fastify просит больше структуры и обычно возвращает это позже. Hono ощущается лёгким и современным, и многим командам это нравится, но та же лёгкость может казаться слишком пустой, если команда ждёт больше встроенных подсказок.

Графики бенчмарков редко ставят точку в споре. Они проверяют чистые запросы на чистом коде. Реальные API тратят время на ожидание базы данных, внешних сервисов, повторные попытки, парсинг, валидацию и неловкие бизнес-правила. В таком мире фреймворк, который экономит одну миллисекунду, значит меньше, чем фреймворк, который делает ошибки заметными.

Привычки команды влияют на результат сильнее, чем признают большинство сравнительных статей. Основатель с одним full stack-разработчиком часто спрашивает: «Что выигрывает в интернете?» Более полезный вопрос: «Что лучше совпадает с тем, как мы уже пишем код, тестируем и отлаживаем?»

Если команда уже мыслит в стиле Express middleware, Express может казаться самым быстрым способом выпустить продукт, даже если типизация там грубее. Если команде нравятся более строгие шаблоны и нужен фреймворк, который подталкивает к более чистому коду, Fastify часто становится удобнее уже после первой недели. Если команде нравится модель Web Request/Response и нужен очень маленький инструмент, Hono может сразу показаться естественным.

Поэтому этот выбор и кажется сложнее, чем должен быть. Идеального победителя нет. Важнее ежедневное удобство. Небольшие backend-проекты обычно идут хорошо, когда фреймворк совпадает с привычками команды, её терпением и готовностью мириться с неудобствами.

Чем три фреймворка отличаются на практике

Express, Fastify и Hono могут одинаково хорошо запускать небольшой API. Разница в том, сколько структуры они дают, сколько требуют от вас и как быстро маленькая команда может выстроить стабильный способ работы.

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

Fastify идёт в противоположную сторону. Он с самого начала подталкивает к plugins, схемам и более организованной форме приложения. Это часто означает больше настройки вначале, но и меньше случайных шаблонов потом. Если команда любит чёткие границы и хочет предсказуемого поведения в продакшене, Fastify часто кажется спокойнее, чем Express.

Hono остаётся маленьким и близким к web standards. Работа с запросами и ответами кажется знакомой, если вам уже нравится Fetch API. Из-за этого его легко читать, и он не перегружает голову. Для TypeScript API Hono часто ощущается легче, чем и Express, и Fastify, особенно если нужен тонкий слой поверх стандартных web primitive, а не фреймворк с ярко выраженным характером.

Коротко это выглядит так: Express позволяет команде самой выбирать шаблоны и следить за их соблюдением. Fastify просит принять больше структуры заранее. Hono просит быть готовыми к более маленькой экосистеме.

И вот это действительно важно. У Express самая широкая поддержка библиотек и больше всего примеров. У Fastify сильная plugin model, и его обычно легко использовать в production, не ощущая тяжести. Hono быстро вырос, потому что ощущается современным и лёгким, но некоторым командам всё равно будет не хватать готовых примеров для редких случаев.

Для команды из двух или трёх человек компромисс довольно понятен. Express проще всего начать, Fastify проще всего держать в порядке, а Hono проще всего сохранять маленьким. Лучший выбор зависит не столько от набора функций, сколько от того, сколько структуры вашей команде нужно каждый день.

Контроль над middleware в повседневной работе

Middleware ощущается по-разному в этих трёх фреймворках, потому что они подталкивают к разным привычкам. Express делает middleware основным способом почти для всего. Fastify даёт hooks и plugins, поэтому поток запроса кажется более структурированным. Hono оставляет цепочку короткой и прямой, и многим командам это нравится для небольшого API.

Express проще всего читать в начале. Сначала вы добавляете middleware на уровне приложения, потом middleware маршрута, потом сам handler. Авторизация, логирование запросов, проверки тела запроса и обработка ошибок хорошо ложатся в эту модель. Но есть одна ловушка — порядок. Поставьте одну функцию не туда, и маршрут может пройти мимо авторизации, залогировать не то или вообще не дойти до обработчика ошибок.

Fastify ощущается строже, и это обычно помогает, когда приложение вырастает больше чем до нескольких файлов. Middleware тоже можно добавлять, но hooks часто выглядят чище, потому что они соответствуют понятным этапам жизненного цикла запроса. preHandler отлично подходит для авторизации. onRequest хорошо работает для логирования и tracing. Ошибки тоже предсказуемее, потому что у Fastify есть понятный способ отправлять и оформлять ответы.

Hono приятен, когда нужен контроль на уровне маршрута без лишней церемонии. Middleware оборачивает handlers в простую цепочку, поэтому авторизация и логирование остаются рядом с маршрутами, которым они нужны. Если вам уже нравится стиль fetch Request и Response, Hono быстро становится естественным. Неудобства начинаются, когда вы добавляете много wrapper-ов, и каждый немного меняет context по-своему. Отладка всё ещё возможна, но нужна дисциплина.

Когда цепочки middleware становятся глубокими, компромиссы видны лучше. Express труднее понимать, потому что порядок выполнения делает много скрытой работы. Fastify дольше остаётся организованным, потому что plugins и hooks дают каждому аспекту своё место. Hono остаётся компактным, но слишком большое количество context helper-ов может сделать поток маршрута менее понятным.

Для повседневной работы авторизация, логирование и ошибки проще всего, когда фреймворк делает путь очевидным. Express даёт свободу, и это здорово, пока приложение не начинает превращаться в беспорядок. Fastify просит больше структуры и обычно возвращает это. Hono держит всё лёгким и удобным для правок, что хорошо работает для небольших сервисов, внутренних API и стартап-инструментов, где команде нужен контроль без лишнего веса фреймворка.

Где проявляется TypeScript-сложность

Если ваш маршрут выглядит как /users/:id?active=true, а тело запроса содержит { "role": "admin" }, сложность обычно не в самом handler. Она начинается, когда вы пытаетесь одинаково типизировать параметры, query, body и данные из middleware по всему запросу.

Express обычно требует больше ручной работы. Request вы типизировать можете, но типы query часто становятся неудобными, типы body зависят от того, что вы к ним прикрепили, а собственные поля на req ведут к declaration merging или type cast. Для крошечного приложения это нормально. На каждом маршруте делать одно и то же быстро надоедает.

Fastify с самого начала ощущается строже. Вы можете задавать Params, Querystring и Body для каждого маршрута, и редактор обычно хорошо подстраивается. Компромисс — больше шума. Небольшой маршрут может обрасти таким количеством generic-типов, что простой код выглядит тяжелее, чем есть на самом деле.

Hono занимает более лёгкую середину. Параметры маршрута задаются просто, а API запроса остаётся чистым. Если добавить schema validation с Zod или похожим инструментом, inference экономит время, потому что одна и та же схема управляет и проверкой, и подсказками в редакторе. Без слоя схем body typing снова скатывается к тем же ручным привычкам, что и в других местах.

Где помогает inference схем

Inference схем особенно полезен, когда API часто меняется. Fastify силён в этом, потому что схемы находятся рядом с определениями маршрутов, и типы остаются рядом с кодом, который их использует. Hono может ощущаться так же гладко, если подобрать правильный валидатор.

Express не мешает библиотекам для схем, но и не встраивает их глубоко в сам фреймворк. Часто вы проверяете данные в одном месте, типизируете запрос в другом и надеетесь, что всё это не разъедется.

Ещё одно место, где всё усложняется, — расширение context. В Express команды часто добавляют req.user, req.org или req.traceId, а потом тратят время на то, чтобы объяснить TypeScript, что такие поля действительно существуют. Fastify делает это чище с помощью plugins и decorators, но типы plugins могут расползаться по кодовой базе. Hono держит context небольшим, но общие переменные становится трудно отслеживать, если постоянно расширять c через множество шагов middleware.

Подсказки редактора быстро показывают разницу. Fastify обычно даёт самые точные подсказки, если всё настроено правильно. Hono ощущается легче и читабельнее. Express сначала кажется дружелюбным, но подсказки там часто слишком свободные, поэтому ошибки доживают до runtime.

Для небольшого backend самый ненадоедливый вариант обычно тот, где структура запроса остаётся понятной, но каждый маршрут не выглядит как упражнение по TypeScript.

Насколько хорошо всё это подходит для продакшена

Пригодность для production сводится к скучным вещам: времени запуска, потреблению памяти, скорости локальной разработки и тому, как код выглядит через несколько месяцев. Для небольшого backend именно это важнее, чем таблицы с бенчмарками.

Hono ощущается самым лёгким. Он быстро стартует, мало ест памяти и почти не оставляет вокруг кода лишнего веса. Это полезно, если API маленький, трафик неровный или позже вы можете перейти на edge runtime. Fastify тоже довольно лёгкий на Node и обычно остаётся эффективным под реальной нагрузкой. Express для крошечного сервиса обычно тоже подходит, но даёт меньше ограничителей, поэтому результат сильнее зависит от того, какие middleware вы навесите сверху.

Чаще всего команда впервые чувствует разницу именно в локальной работе. Express легко открыть и изменить, особенно если команда его уже знает. Fastify требует чуть больше структуры в начале, но эта структура может сэкономить время, когда маршруты, валидация и логирование начинают расползаться по приложению. Hono тоже ощущается быстрым в повседневной работе, потому что его API небольшой и легко помещается в голове.

Картина довольно ясна: Express лучше всего работает, когда сервис останется на Node и вам нужен самый короткий путь к релизу. Fastify лучше всего подходит, когда вам нужна производительность Node и более сильная структура приложения. Hono особенно уместен, когда Node — только один из вариантов, а позже может понадобиться edge deployment.

Глубина plugins — это место, где простота маленького приложения может превратиться в неудобство. У Fastify более глубокая plugin model, и это помогает, когда небольшой API вырастает в auth, webhooks, jobs и admin routes. Express сначала остаётся простым, но через полгода два разработчика могут решить одну и ту же задачу по-разному. Hono остаётся приятным, пока сервис остаётся тонким. Если приложению нужны старые Node middleware, работа с файлами или очень специфические server hooks, Express и Fastify обычно ощущаются естественнее.

Небольшой startup admin API хорошо показывает этот компромисс. Express быстро выпускает первую версию. Fastify часто выглядит чище к шестому месяцу. Hono — сильный вариант, когда нужна минимальная поверхность и возможность выйти за пределы обычного Node-сервера.

Если бы я ожидал одного поддерживающего разработчика, несколько endpoint-ов и обычный Node-хостинг, я бы скорее выбрал Fastify. Если бы мне нужна была поддержка edge или максимально лёгкий runtime, я бы скорее выбрал Hono. Express всё ещё имеет смысл, когда команда хорошо его знает и хочет выпускать продукт почти без церемонии.

Простой пример: admin API для стартапа

Представьте небольшой admin API для стартапа. Сначала им пользуются два человека: основатель и операционный менеджер. Им нужно входить в систему, просматривать клиентов, менять статус аккаунтов и видеть, кто и что менял.

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

Вот здесь выбор становится проще оценить. Вы не выбираете фреймворк для огромной платформы. Вы выбираете его для backend, который должен оставаться аккуратным не только после первого маршрута, но и после десятого.

Для первой версии Hono часто оказывается самым аккуратным. Файлы маршрутов остаются короткими, middleware легко разместить, а код читается чисто. Если вам нужно запустить внутренний инструмент уже на этой неделе, Hono ощущается лёгким, но не хлипким.

Express по-прежнему работает, и многие команды двигаются с ним быстрее всего, потому что уже его знают. Но здесь важна дисциплина. Логин, валидация и логирование могут быстро расползтись по helper-ам и custom middleware. Простой API может стать грязным, если каждый маршрут решает одну и ту же задачу немного по-своему.

Fastify обычно просит больше структуры в самом начале. На первый день это не всегда приятно, но польза приходит быстро. Валидация, схемы маршрутов и логирование складываются более организованно, поэтому кодовая база остаётся спокойнее, когда небольшой backend начинает вести себя как настоящий продукт.

Допустим, через три месяца стартап добавляет role-based access, историю аудита, массовые обновления и более строгие правила ввода. Hono и это нормально потянет, но вам придётся принимать больше архитектурных решений самостоятельно. Express тоже справится, хотя команды часто снова и снова чинят одни и те же шероховатости.

Fastify — тот вариант, которому я больше всего доверяю, когда требования растут. Он даёт достаточно структуры, чтобы избежать расползания, не превращая небольшой backend в проект, перегруженный церемонией.

Если admin API действительно маленький и важнее всего скорость, Hono — умный выбор. Если вы ожидаете, что панель вырастет в серьёзную внутреннюю систему, Fastify обычно безопаснее. Express подходит, когда у команды уже выстроились сильные привычки и знакомость важнее защитных ограничений.

Как выбрать шаг за шагом

Начинайте с ограничений, а не с фреймворка. Поддерживать небольшой backend проще, когда вы заранее решили, где он будет работать, как он будет проверять входные данные и кто будет чинить баги в два часа ночи. Спор сразу становится проще, как только эти ограничения записаны на бумаге.

1. Начните с runtime и хостинга. Если вам нужны edge runtime, web standard APIs или очень маленькие деплои, Hono часто подходит быстрее. Если вы точно знаете, что будете работать на классическом Node-сервере с более долгим жизненным циклом процесса и более богатыми server features, Fastify обычно ощущается естественнее. Express нормально работает на обычном Node, но даёт меньше подсказок.

2. Посчитайте, какие plugins вам действительно нужны. Не список мечты, а реальный список. Если backend требует логирования, hooks для авторизации, валидации, документации и нескольких типичных интеграций, у Fastify сильные аргументы. Если у приложения всего несколько маршрутов, одна база данных и один слой авторизации, Hono поможет держать всё чище.

3. Выберите подход к валидации до того, как начнёте писать маршруты. Это решение влияет почти на каждый файл. Если команде нужен направляющий шаблон и более жёсткая структура, поможет Fastify. Если команде нравятся небольшие handlers и собственные инструменты, Hono не будет мешать. Express может и то и другое, но вам придётся собрать больше частей самостоятельно.

4. Выберите фреймворк, который команда сможет спокойно отлаживать. Для большинства небольших сервисов это важнее бенчмарков. Команда из двух человек, которая уже знает Express, сегодня может быстрее выпустить продукт именно с ним, даже если Hono или Fastify на бумаге выглядят лучше. Но если команда постоянно борется с типами, plugins или порядком middleware, «безопасный» выбор перестаёт быть безопасным.

Рабочее простое правило такое: берите Hono для очень лёгких API, Fastify для небольших backend, которые могут вырасти в более структурированный сервис, а Express — только тогда, когда знакомство с ним явно перевешивает компромиссы в типизации.

Ошибки, которые отнимают время

Команды часто теряют больше времени не на сам фреймворк, а на всё, что вокруг него. Небольшой API с 10 или 20 маршрутами редко ломается потому, что один фреймворк выиграл бенчмарк. Он становится грязным, потому что код перестаёт следовать одному понятному шаблону.

Первая ловушка — гнаться за графиками скорости для крошечного сервиса. Для большинства небольших backend запросы к базе, проверки авторизации и внешние API занимают больше времени, чем router. Если один запрос проводит 40 мс в PostgreSQL, экономия 1 мс на уровне фреймворка мало что изменит.

Ещё одна тихая проблема — смешивать подходы к валидации между маршрутами. Один handler проверяет поля вручную, другой использует schema, а третий доверяет типам TypeScript, которые в runtime исчезают. Неделю это работает. Потом ответы об ошибках начинают различаться, крайние случаи пролезают, и никто уже не помнит, какой маршрут живёт по какому правилу.

TypeScript тоже может отнимать время, если форма API ещё меняется каждые несколько дней. Команды часто строят аккуратные generic helpers, общие wrappers и глубокие типы запроса ещё до того, как поймут, как будут выглядеть endpoint-ы через месяц. Потом простое изменение продукта превращается в длинную уборку. Сначала держите типы рядом с каждым маршрутом. Переносите их в общие helper-ы только тогда, когда один и тот же шаблон повторился достаточно много раз.

Ограничения деплоя тоже всплывают позже, чем должны. Фреймворк может казаться идеальным на ноутбуке и начать раздражать на целевом хосте из-за cold start, лимитов памяти, требований к логированию или отсутствия поддержки runtime. Это важнее, чем многие думают. У крошечного внутреннего admin API и у загруженного публичного сервиса разные потребности, так что тестируйте там, где он реально будет работать.

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

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

Быстрые проверки перед окончательным решением

Фреймворк может отлично выглядеть в демо, а потом начать раздражать, когда начинается реальная работа. Прежде чем закрепить выбор, соберите один небольшой защищённый маршрут и изучите его построчно.

Хороший тест — маршрут вроде POST /admin/users: ему нужны авторизация, валидация входных данных, один запрос к базе и один понятный путь ошибки. Один такой маршрут показывает большую часть будущей боли.

Попросите нового разработчика проследить запрос от входного файла до финального handler. Если ему нужно прыгать через слишком большое количество plugins, wrappers или магических helper-ов, код будет стареть плохо.

Прочитайте код авторизации и валидации вслух. Если удачный сценарий прячется за setup-кодом, а логика маршрута растворяется в decorators и hooks, ежедневные изменения будут казаться слишком медленными.

Сначала проверьте runtime, а не в самом конце. Hono часто проще всего подходит, если вы можете работать на edge platform или смешивать runtime. Fastify лучше всего чувствует себя на Node. Express по-прежнему работает, но он даёт меньше помощи и требует больше ручной связки в TypeScript-проектах.

Удалите одну библиотеку из тестового маршрута и замените её другой. Если такая простая замена затрагивает все handler-ы, значит, фреймворк и приложение слишком тесно переплетены.

Попробуйте скучный тест на поддержку

Вернитесь к тестовому маршруту на следующий день и измените одно правило. Добавьте обязательное поле, ужесточите авторизацию или поменяйте формат ошибки. Посчитайте, сколько файлов пришлось тронуть.

Для небольшого backend это важнее бенчмарков. Маленькие команды страдают не от потери пары миллисекунд. Они страдают, когда простые правки расходятся по шести файлам и ломают проверки типов ещё в двух.

Если маршрут остаётся читабельным, runtime поддерживает его чисто, а библиотеки лежат за тонкими границами, скорее всего, у вас хороший выбор TypeScript backend.

Что делать дальше

Не выбирайте фреймворк только по бенчмаркам или числу звёзд на GitHub. Сначала соберите один реальный endpoint. Возьмите то, что backend действительно будет делать: создать запись клиента, загрузить файл или обработать webhook с повторными попытками.

Такой небольшой тест расскажет больше, чем длинная таблица функций. Вы увидите, где код ощущается чистым, где типы начинают мешать и сколько настройки ваша команда готова терпеть в обычную неделю.

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

Если фреймворк приятен только до того, как вы добавили эти части, считайте это предупреждением. Небольшие backend остаются маленькими всего пять минут. Как только появляются реальные пользователи, слабая обработка ошибок, неудобный middleware и грязные типы начинают стоить времени.

Особенно внимательно смотрите на сценарии с ошибками. Отправьте плохие данные. Вызовите timeout. Верните ошибку базы данных. Проверьте, насколько легко сохранять ответы последовательными. Потом задеплойте всё и обратите внимание на скучные вещи: шаги сборки, настройку окружения, время запуска и вывод логов. Обычно именно это важнее, чем хитрый API router.

Если команда небольшая, будьте честны насчёт поддержки. Express по-прежнему работает, но, возможно, вам придётся потратить больше усилий, чтобы превратить его в строгий TypeScript-набор. Fastify часто ощущается более цельным для production-работы. Hono может отлично подойти, когда нужен лёгкий codebase и жёсткий контроль, особенно если вам нравится более простой mental model.

Если выбор всё ещё кажется близким, поможет внешняя оценка. Oleg Sotnikov на oleg.is работает с founder-ами и небольшими командами над архитектурой стартапов, backend-решениями и Fractional CTO work. Короткая консультация может сэкономить недели переделок, если вы вот-вот слишком рано зафиксируете стек.

Выберите один endpoint, проверьте острые углы и возьмите тот фреймворк, который команда будет по-прежнему любить после первого инцидента на дежурстве.