Cloudflare Workers: где они реально выигрывают у обычного backend и где ломаются

Cloudflare Workers: где они реально выигрывают у обычного backend и где ломаются

Workers берут не «серверless ради моды», а когда нужен короткий путь от запроса до ответа: edge-логика, редиректы, A/B-проверки, подмена заголовков, лёгкий API-gateway, кэширование и фильтрация трафика. Для этих задач они часто проще, чем поднимать отдельный сервис на VM или в контейнере.

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

Хорошее правило: Workers ставят на входе системы, а не в её сердце. То есть они удобны для авторизации на краю, маршрутизации, rate limit, простых интеграций и glue-кода между сервисами. Если нужна база, очередь или транзакционная логика — вынеси это в отдельный backend, а Worker оставь тонким слоем.

Ещё одна частая ошибка — пытаться хранить в Worker то, что должно жить в внешнем storage. Для временных данных используй кэш, KV или Durable Objects только там, где нужна координация. Иначе получишь код, который сложно тестировать и ещё сложнее мигрировать.

Если проекту нужен быстрый edge-слой без лишней инфраструктуры, Workers — сильный выбор. Если ядро продукта уже завязано на сложный runtime, не пихай туда всё подряд: тонкий Worker почти всегда полезнее, чем «мини-монолит» на краю.