Cloudflare Workers ломаются не на коде, а на неправильной границе ответственности

Cloudflare Workers ломаются не на коде, а на неправильной границе ответственности

Workers хороши там, где нужен edge_compute: быстрый роутинг, легкая нормализация запросов, A/B на заголовках, защита от мусора, проксирование к origin. Но если пытаться запихнуть в них тяжелую бизнес-логику, сложные сессии и большие ответы, вы получите лишнюю сложность без выигрыша в ssr.

Проверьте три вещи до запуска:
— есть ли у функции четкая роль: принять, изменить, переслать;
— не тянет ли она лишние зависимости и большой runtime;
— можно ли отдать кеширование на уровень CDN или isr, а не собирать его вручную в коде.

Частая ошибка — использовать Workers как «мини-бэкенд для всего». Тогда появляются гонки за состояние, странные зависимости от времени выполнения и трудный дебаг. Правильнее держать в Workers только то, что обязано жить на краю сети: быстрые проверки, редиректы, подмена хедеров, защита от ботов, маршрутизация.

Если упростить правило: Worker должен делать меньше, чем Next.js-страница, и быстрее, чем ваш origin. Все остальное лучше оставить на стороне приложения, где проще поддерживать логику, наблюдаемость и предсказуемый deploy на vercel.