Cloudflare Workers: serverless функции на Edge

Cloudflare Workers — это serverless платформа для запуска JavaScript/TypeScript кода на Edge-серверах Cloudflare по всему миру. Код выполняется в ближайшем к пользователю дата-центре без холодного старта.

Бесплатный план Workers

Первый Worker

// Простой Worker — отвечает на все запросы
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // Редирект old → new
    if (url.pathname === '/old-page') {
      return Response.redirect('https://example.com/new-page', 301);
    }
    
    // Добавить заголовки безопасности
    const response = await fetch(request);
    const newResponse = new Response(response.body, response);
    newResponse.headers.set('X-Frame-Options', 'DENY');
    newResponse.headers.set('X-Content-Type-Options', 'nosniff');
    return newResponse;
  }
};

Деплой через Wrangler CLI

# Установить Wrangler
npm install -g wrangler

# Авторизоваться
wrangler login

# Создать проект
wrangler init my-worker

# Деплой
wrangler deploy

Полезные примеры Workers

• Георедирект — перенаправлять пользователей на локальную версию сайта по стране
• A/B тестирование — случайно распределять трафик между версиями
• Трансформация ответов — изменять HTML «на лету» без деплоя
• Заголовки безопасности — добавлять CSP, HSTS к каждому ответу
• Rate Limiting API — ограничивать запросы с логикой на Worker

Workers в сравнении с традиционным backend

Разбор ошибок Workers

Error 1101: Worker threw exception

Необработанное исключение в коде Worker — чаще всего обращение к undefined-переменной, ошибка в Promise без вызова .catch(), или неверный доступ к телу запроса (например, повторное чтение request.body, который можно прочитать только один раз). Логи смотрите через wrangler tail в реальном времени или в Dashboard → Workers → Logs.

Error 1102: Worker exceeded resource limits

Worker превысил лимит CPU-времени на бесплатном плане или ушёл в бесконечный цикл. В отличие от классического таймаута сервера, здесь считается именно активное CPU-время выполнения, а не время ожидания ответа от внешнего API — долгий fetch к медленному бэкенду сам по себе не расходует этот лимит.

Проверка что Worker работает

# Посмотреть живые логи Worker
wrangler tail my-worker

# Проверить что Worker действительно обрабатывает маршрут
curl -I https://example.com/old-page
# Ожидаемо: HTTP/2 301 и заголовок location из кода Worker

Когда Workers не подходят

• Нужен постоянный доступ к файловой системе или запуск бинарных зависимостей ОС — Worker выполняется в изолированной V8-песочнице без файловой системы и без Node.js API в полном объёме.
• Нужны долгие фоновые вычисления (минуты, а не миллисекунды) — для этого больше подходит обычный сервер или очередь задач с воркером на VPS.
• Нужно хранить и раздавать большие файлы из самого Worker — для этого Worker обращается к R2 через bindings, а не хранит данные в себе.

У Worker есть доступ к переменным окружения и секретам через объект env, который передаётся в функцию fetch. Секреты (API-ключи, токены) задаются командой wrangler secret put NAME и не попадают в открытом виде в код или репозиторий — в отличие от обычных переменных из wrangler.toml.

Локальная отладка перед деплоем делается командой wrangler dev — она поднимает Worker на локальной машине с эмуляцией окружения Cloudflare, включая Workers KV и R2 bindings, без необходимости деплоить каждое изменение в продакшен для проверки.

Ошибка «script startup exceeded CPU time limit» отличается от Error 1102 тем, что относится не к обработке запроса, а к самому запуску кода модуля — обычно её вызывает тяжёлая инициализация на верхнем уровне файла (например, синхронный парсинг большого JSON при старте), которую стоит перенести внутрь обработчика запроса или закешировать между вызовами.

Несколько Workers можно связать друг с другом через Service Bindings — один Worker вызывает другой напрямую, без HTTP-запроса через интернет, с минимальной задержкой, что удобно для разделения большого проекта на модули без роста стоимости.