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-запиту через інтернет, з мінімальною затримкою, що зручно для поділу великого проєкту на модулі без зростання вартості.