Когда после ASP.NET Core и NestJS пробуешь писать API на Cloudflare Workers, не хватает привычной структуры. Hono хорош для простых хендлеров, но для сложных сервисов хочется контроллеров, DI-контейнера и строгой типизации на всех уровнях. Так появился Flare TS — фреймворк, который я протестировал на реальном проекте.
Почему не Hono и не NestJS
Hono — отличный минималистичный роутер для Workers, но:
- Нет встроенной валидации входных данных
- Middleware работают по принципу “надеюсь, что предыдущий middleware положил нужные данные в context”
- Приходится вручную собирать структуру приложения
NestJS решает эти проблемы, но:
- Не работает на Cloudflare Workers из-за Node.js-специфичных зависимостей
- Тяжеловесный DI-контейнер
- Валидация происходит в runtime
Flare TS берёт лучшее от обоих подходов:
// Пример контроллера
@controller('/users')
class UserController {
constructor(private readonly userService: UserService) {}
@get('/:id')
async getById(
@param('id', { format: 'uuid' }) id: string,
@query('expand') expand?: string[],
) {
return this.userService.getById(id, expand);
}
}
Фичи, которые реально экономят время
Build-time validation — фреймворк проверяет на этапе сборки:
- Все ли роуты зарегистрированы
- Соответствуют ли типы параметров между middleware и хендлерами
- Корректны ли схемы валидации
# Ошибка: параметр 'id' не соответствует формату UUID
Error: Route /users/:id failed validation:
- param 'id' must match format 'uuid'
Типизированный контекст запроса — больше никаких context.locals.user as User. Middleware объявляет, какие данные добавляет, а хендлеры — какие ожидают:
// Middleware
@middleware()
class AuthMiddleware {
async handle(req: Request, ctx: RequestContext<{}, { user: User }>) {
ctx.set('user', await getUserFromToken(req));
}
}
// Хендлер
@get('/profile')
async getProfile(@ctx() ctx: RequestContext<{ user: User }>) {
return ctx.require('user'); // Тип User гарантирован
}
Один код для Node и Cloudflare — адаптер выбирается при инициализации приложения:
// Для Node.js
const host = new NodeHost(app);
// Для Cloudflare Workers
const host = new CloudflareHost(app);
Подводные камни v0.1
-
Нет готовых адаптеров для тестирования — автор предлагает прогонять запросы через реальный pipeline, но для интеграционных тестов это не всегда удобно.
-
Ограниченный набор валидаторов — пока только базовые проверки типов и форматов. Для сложных сценариев придётся писать кастомные правила.
-
Документация в процессе — некоторые фичи вроде кастомных DI-провайдеров приходится разбирать по исходникам.
Кому стоит попробовать
Flare TS — хороший выбор, если:
- Вы пишете API, которое должно работать и на Node.js, и на Cloudflare Workers
- Устали от ручной валидации параметров запроса
- Хотите больше статической типизации в HTTP-слое
Пока рано переносить на него production-проекты, но для нового микросервиса или edge-функции — отличный повод поэкспериментировать. Особенно если, как и автор, вы скучаете по ASP.NET Core в мире TypeScript.
Лично мне не хватает встроенной поддержки OpenAPI, но в issues уже есть соответствующий запрос. Возможно, к v1.0 фреймворк обрастёт всем необходимым для серьёзных проектов.