Що таке Cloudflare Workers і коли edge-код простіший за окремий сервер

Hook

Cloudflare Workers — це маленький шматок коду, який живе на edge і реагує майже одразу. Для дрібних задач це часто простіше, ніж піднімати окремий сервер і тягнути за ним ще півінфраструктури.

Problem / Context

Не кожна задача заслуговує на повноцінний backend. Якщо треба перенаправити стару адресу, перевірити доступ, підправити заголовки, зловити webhook або віддати швидку відповідь, окремий сервер часто виходить занадто важким.

Cloudflare Workers працюють як serverless-логіка: ти запускаєш код близько до користувача, а не десь на одному центральному сервері. У простих сценаріях це дає менше затримки, менше рухомих частин і менше шансів щось забути під час релізу.

Why it matters

Workers корисні там, де важливі:

• швидка реакція;
• простий деплой;
• мінімум серверного обслуговування;
• однакове поводження для всіх користувачів;
• маленька логіка, яку не хочеться виносити в окремий сервіс.

Але є й межа. Якщо тобі потрібні довгі фонові задачі, складна бізнес-логіка або великий стан, edge уже не завжди найкраще місце. Тут Workers — не чарівна паличка, а зручний інструмент для вузького класу задач.

Illustration

Cloudflare Workers стоять між користувачем і origin server. Легка логіка виконується на edge, а важку частину можна лишити на origin server. Саме тому дрібні зміни — редирект, фільтр, заголовок, захист, webhook — часто краще робити тут, а не на окремому сервері.

How to do it

1. Почни з маленького кейсу

Не намагайся одразу перенести весь backend. Workers найкраще працюють там, де треба швидко вирішити одну задачу.

2. Напиши мінімальний Worker

export default {
  async fetch(request) {
    const url = new URL(request.url)

    if (url.pathname === "/old") {
      return Response.redirect("https://example.com/new", 301)
    }

    const response = await fetch(request)
    const headers = new Headers(response.headers)
    headers.set("X-Edge-Handled", "yes")

    return new Response(response.body, {
      status: response.status,
      headers,
    })
  },
}

Цей приклад робить дві прості речі: перекидає старий шлях на новий і додає заголовок до звичайної відповіді.

3. Прив’яжи route

Після цього додай route для домену або піддомену. Route каже Cloudflare, для яких адрес Worker має запускатися.

4. Перевір відповідь до релізу

Подивись, що реально повертає Worker: статус, заголовки, редирект, тіло відповіді. Тут легше зловити помилку, ніж після викочування.

5. Додавай binding тільки коли він потрібен

Якщо Worker має читати secrets, звертатися до сховища або до іншого сервісу, підв’яжи binding. Не додавай зайвого на старті — маленький Worker має лишатися маленьким.

6. Лишай origin server для важкого

Якщо потрібно довго рахувати щось, тримати складний стан або обробляти великі обсяги даних, краще не тягнути це в edge. Worker може прийняти запит, а основну роботу лишити origin server.

7. Для зовнішніх подій використай webhook обережно

Workers зручні як перший приймач webhook. Але не перетворюй їх на сховище всіх рішень. Прийшов webhook, перевірив підпис, швидко відповів, передав далі — цього часто досить.

Anti-patterns

• переносити в Workers весь backend без потреби;
• зберігати великий state у коді, який має бути коротким;
• робити важкі обчислення на edge;
• додавати bindings і route-и про запас;
• підміняти ними нормальний server лише тому, що це модно;
• забувати про обмеження платформи і про те, що не кожен кейс виграє від edge.

Conclusion / Action plan

Якщо задача маленька, спитай себе: її краще вирішити на edge чи на origin server? Якщо відповідь схиляється до edge, починай з мінімального Worker.

Що зробити далі:

1. випиши одну конкретну задачу;
2. перевір, чи її можна вирішити без окремого сервера;
3. якщо так — зроби мінімальний Worker;
4. додай route;
5. лиши origin server тільки для важкого.