Cloudflare Workers w praktyce — Twój kod na krawędzi sieci

Przez lata architektura webowa wyglądała tak samo: przeglądarka użytkownika po jednej stronie, serwer (albo chmura) po drugiej, a między nimi — setki lub tysiące kilometrów kabli. Edge computing wywraca ten układ: kod uruchamia się nie w jednym centrum danych, ale w setkach lokalizacji na całym świecie, możliwie najbliżej użytkownika. Cloudflare Workers to najpopularniejsza i naszym zdaniem najdojrzalsza implementacja tego pomysłu. W tym artykule pokazujemy, jak działają Workery, jak napisać i wdrożyć pierwszy skrypt oraz do czego używamy ich w codziennych projektach.

Czym są Cloudflare Workers?

Workers to platforma serverless działająca w ponad 300 lokalizacjach sieci Cloudflare. Kiedy użytkownik z Warszawy wysyła żądanie do Twojej aplikacji, kod wykonuje się w warszawskim punkcie obecności — a nie w serwerowni we Frankfurcie czy Wirginii. Efekt: opóźnienia liczone w pojedynczych milisekundach.

Techniczna ciekawostka, która odróżnia Workers od klasycznych funkcji serverless (AWS Lambda, Google Cloud Functions): zamiast kontenerów Cloudflare używa izolatów V8 — tego samego mechanizmu, którym przeglądarka Chrome separuje karty. Izolat startuje w ułamku milisekundy, więc problem „zimnego startu”, który w Lambdzie potrafi dodać sekundę opóźnienia, tu praktycznie nie istnieje. Płacimy za to pewnymi ograniczeniami: kod musi być JavaScriptem/TypeScriptem (lub kompilować się do WebAssembly), a zamiast API Node.js dostajemy standardowe Web API — fetch, Request, Response, URL, crypto.

Model programowania: wszystko jest żądaniem

Worker to w najprostszej postaci funkcja, która dostaje obiekt Request i musi zwrócić obiekt Response. Minimalny przykład:

export default {
  async fetch(request, env, ctx) {
    return new Response("Witaj z krawędzi sieci!", {
      headers: { "content-type": "text/plain; charset=utf-8" }
    });
  }
};

Jeśli pisałeś kiedyś kod frontendowy korzystający z fetch, poczujesz się jak w domu — to dokładnie te same interfejsy, tylko po drugiej stronie połączenia. Worker może żądanie obsłużyć w całości sam, może je zmodyfikować i przekazać dalej do Twojego serwera (tryb proxy), a może też sam wywołać dowolne zewnętrzne API.

Pierwszy projekt w 5 minut

Do pracy z Workers służy narzędzie Wrangler. Nowy projekt zakładamy jednym poleceniem:

npm create cloudflare@latest my-worker
cd my-worker
npx wrangler dev      # lokalne środowisko deweloperskie
npx wrangler deploy   # wdrożenie na produkcję

wrangler dev uruchamia lokalny serwer symulujący środowisko edge (z hot-reloadem), a wrangler deploy publikuje kod globalnie — w kilkanaście sekund skrypt działa na całym świecie pod adresem *.workers.dev albo pod Twoją domeną podpiętą do Cloudflare.

Do czego używamy Workerów w praktyce?

1. Nagłówki bezpieczeństwa i drobne poprawki bez ruszania backendu

Klasyczny scenariusz: strona działa na hostingu współdzielonym albo na starym systemie, w którym zmiana konfiguracji serwera jest kłopotliwa. Worker może dokleić nagłówki do każdej odpowiedzi:

export default {
  async fetch(request) {
    const response = await fetch(request);
    const fresh = new Response(response.body, response);
    fresh.headers.set("Strict-Transport-Security", "max-age=31536000");
    fresh.headers.set("X-Content-Type-Options", "nosniff");
    fresh.headers.set("Referrer-Policy", "strict-origin-when-cross-origin");
    return fresh;
  }
};

2. Przekierowania i porządki w URL-ach

Migracja sklepu zmieniła strukturę adresów? Zamiast utrzymywać setki reguł w .htaccess, logikę przekierowań można trzymać w Workerze — z pełną mocą JavaScriptu: mapy przekierowań, wyrażenia regularne, reguły zależne od kraju czy urządzenia.

3. Proxy do API z ukrytym kluczem

Frontend potrzebuje danych z płatnego API, ale klucza nie wolno pokazać w przeglądarce. Worker robi za bezpiecznego pośrednika:

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const target = "https://api.example.com" + url.pathname;
    return fetch(target, {
      headers: { "Authorization": "Bearer " + env.API_KEY }
    });
  }
};

Klucz trafia do zmiennej środowiskowej (wrangler secret put API_KEY) i nigdy nie opuszcza infrastruktury Cloudflare.

4. Testy A/B bez migotania strony

Klasyczne narzędzia A/B podmieniają treść JavaScriptem już po załadowaniu strony — użytkownik widzi „przeskok”. Worker może podzielić ruch na warianty jeszcze zanim odpowiedź opuści sieć Cloudflare: przydziela wariant, zapisuje go w ciasteczku i serwuje właściwą wersję od pierwszego bajta.

5. Personalizacja geograficzna

Każde żądanie niesie obiekt request.cf z informacjami o kraju, mieście czy strefie czasowej użytkownika. Przełączenie waluty, języka albo treści banera dla odwiedzających z innego kraju to dosłownie kilka linijek.

Limity i koszty

Plan darmowy pozwala na 100 tysięcy żądań dziennie z limitem 10 ms czasu procesora na żądanie — w zupełności wystarcza na przekierowania, nagłówki czy proste proxy. Plan płatny (5 USD miesięcznie) daje 10 milionów żądań i limit CPU rzędu dziesiątek milisekund, co starcza nawet na renderowanie stron czy obróbkę danych. Ważny niuans: liczy się czas procesora, nie czas oczekiwania — gdy Worker czeka na odpowiedź zewnętrznego API, licznik stoi.

Czego Workery same nie potrafią?

Izolat z definicji niczego nie pamięta między żądaniami — nie ma dysku ani wspólnej pamięci. Do przechowywania stanu Cloudflare oferuje osobne usługi, które podpina się do Workera tak zwanymi bindingami: KV (błyskawiczny magazyn klucz-wartość), R2 (obiektowy storage w stylu S3), D1 (SQLite na edge’u) i Durable Objects (spójny stan i koordynacja). Dwóm pierwszym przyjrzymy się dokładnie w kolejnych artykułach z tej serii — już za dwa tygodnie KV, a po nim R2.

Podsumowanie

Cloudflare Workers zdejmują z barków cały ciężar utrzymania serwerów, a jednocześnie dają coś, czego klasyczny hosting dać nie może: wykonanie kodu kilkanaście milisekund od użytkownika, w 300 miejscach naraz. W Okinet sięgamy po nie zarówno w dużych projektach (API, personalizacja, cache), jak i do drobnych usprawnień istniejących stron — bo często kilkadziesiąt linijek na edge’u załatwia to, co wymagałoby przebudowy backendu. Jeśli zastanawiasz się, czy edge computing ma sens w Twoim projekcie — porozmawiajmy.