<b>Cloudflare Workers ломают не код, а ожидания от серверной логики</b>

<b>Cloudflare Workers ломают не код, а ожидания от серверной логики</b>

Workers удобны там, где нужна быстрая edge-обработка: редиректы, A/B-маршрутизация, заголовки, кэш-правила, лёгкий API-слой. Но это не мини-Node.js. Если тащить внутрь тяжёлые библиотеки, файловую систему, долгие фоновые задачи или stateful-подход, получаются странные баги и лишние часы дебага.

За неделю в репах обычно всплывают одни и те же ошибки:
— надеются на полноценный runtime и не проверяют ограничения окружения;
— пишут бизнес-логику как в обычном backend, хотя лучше вынести её в API или очередь;
— забывают, что cold path должен быть коротким: парсинг, валидация, ответ;
— смешивают edge-логику с доступом к БД без кэша и таймаутов.

Если нужен Worker в проде, держите правило: он должен решать один маленький слой задачи. Всё, что требует длительных вычислений, сложных зависимостей или большой памяти, уводите наружу. А вот то, что выигрывает от географии и скорости ответа, оставляйте на edge. Для авторизации, прокси, шифрования токенов, шринка URL и маршрутизации это почти идеальная зона.

Есть наблюдение которое стоит проверить: чем меньше кода в Worker, тем проще миграции между сервисами и тем дешевле поддержка. Не потому что серверлесс магия, а потому что границы ответственности становятся очевидными.

Если Worker начинает расти, первым делом режьте его обратно до маршрутизатора и тонкого адаптера.