Migrare da Pages a Workers: quando ha senso e il costo reale del cambiamento

I team adottano Pages perché il flusso push git con creazione automatica e distribuzione istantanea è davvero più semplice rispetto alla creazione di una pipeline CI da zero. Questo è un vantaggio reale, non marketing. Il problema appare quando il progetto cresce e inizi a raggiungere limiti che Pages non può risolvere: trigger cron, più lavoratori con responsabilità separate, stadiazione con vincoli diversi. A questo punto, la migrazione a Workers sembra ovvia, ma il suo costo reale raramente viene calcolato prima di iniziare.

La vera migrazione si innesca

Il trigger più comune sono i trigger cron. Pages non supporta cron in modo nativo. Se hai bisogno di un lavoro che viene eseguito periodicamente (elaborazione di pagamenti, sincronizzazione di dati esterni, generazione di report pianificati) hai già un Worker separato in esecuzione insieme al tuo progetto Pages. Man mano che il numero di lavoratori satellite cresce, il team inizia a chiedersi se non avrebbe più senso consolidare tutto nei lavoratori.

Il secondo fattore scatenante è la frammentazione della distribuzione. Un progetto Pages è un'unità di distribuzione monolitica: frontend, funzioni, tutto insieme. Quando vuoi dividere le responsabilità tra lavoratori specializzati (uno per l'API pubblica, uno per l'elaborazione interna, uno per i webhook), Pages non offre questa granularità. La distribuzione di una modifica al gestore dei webhook attiva una ricostruzione dell'intero frontend.

Il terzo è la messa in scena con parità di produzione. Le pagine dispongono di ambienti di produzione e di anteprima, ma non hanno ambienti denominati con associazioni completamente diverse. Se desideri un database D1 in staging completamente separato da quello di produzione, con variabili di ambiente diverse e magari anche un modello KV diverso, la soluzione in Pages è creare un progetto Pages separato e gestire la sincronizzazione manualmente. In Lavoratori, questo è in wrangler.toml con i blocchi [env.staging] e [env.production].

Cosa perdi quando lasci Pages

Prima della migrazione, il calcolo corretto è elencare le offerte di Pages che dovrai sostituire.

La pipeline di costruzione è l'elemento più sottovalutato. Pages si connette al repository, rileva il framework, esegue la build e carica le risorse. In Workers, ti assumi questa responsabilità: possiedi CI/CD (GitHub Actions, GitLab CI, qualunque cosa), crea script e carica risorse su R2 se hai ancora bisogno di servire file statici.

Le distribuzioni di anteprima per ramo sono il secondo elemento. Pages genera automaticamente un URL di anteprima per ciascun ramo: push, URL disponibile, commento su PR. Replicarlo in Workers richiede lavoro: uno script CI che rileva il nome del ramo, distribuisce con un nome Worker derivato dal ramo (minha-api-pr-247) e commenta l'URL nel PR tramite l'API GitHub. Funziona, ma è un codice infra che scrivi e mantieni.

Il terzo elemento è il CDN per le risorse statiche. Questo è il più costoso da ignorare.

Il conto dei beni statici

In Pages, le risorse statiche (HTML, CSS, JS, immagini) vengono servite direttamente dal CDN Cloudflare senza attivare il runtime di Workers. Ogni richiesta per una risorsa statica costa $ 0 per richiesta, indipendentemente dal volume.

In Workers, non hai questo primitivo nativamente. Per servire le risorse, sono necessari R2 (object storage) e la logica nel Worker che cerca la risorsa corretta, applica le intestazioni della cache e restituisce il contenuto. Ogni richiesta che passa attraverso il runtime conta come un'invocazione di Worker.

Il piano retribuito per i lavoratori include 10 milioni di richieste al mese e in eccesso addebita 0,30 dollari per milione. Un sito web con 100 milioni di richieste mensili, di cui 90 milioni per asset statici: su Pages il costo della richiesta è 0$. In Workers ci sono 90 milioni di chiamate oltre il pacchetto incluso: 27 dollari al mese solo per questo delta, che cresce linearmente con il traffico.

Per un sito web con 500 milioni di richieste mensili con l'85% di asset statici: la differenza ammonta a più di 120 dollari al mese. Il costo del piano Pages Pro è di $ 20 al mese. La migrazione verso Workers, in questo scenario, è una decisione che aumenta i costi operativi in cambio di flessibilità.

Il file wrangler.toml per servire le risorse R2

Se la migrazione ha senso nonostante i costi, il modello corretto per servire le risorse statiche in Workers utilizza R2 con Cache API:

# wrangler.toml
name = "meu-site"
main = "src/index.ts"
compatibility_date = "2024-09-24"

[[r2_buckets]]
binding = "ASSETS"
bucket_name = "meu-site-assets"

[[routes]]
pattern = "meusite.com/*"
zone_name = "meusite.com"

// src/index.ts
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const cache = caches.default;
    const cached = await cache.match(request);
    if (cached) return cached;

    const url = new URL(request.url);
    const key = url.pathname.slice(1) || "index.html";
    const object = await env.ASSETS.get(key);

    if (!object) {
      return new Response("Not Found", { status: 404 });
    }

    const response = new Response(object.body, {
      headers: {
        "Content-Type": object.httpMetadata?.contentType ?? "application/octet-stream",
        "Cache-Control": "public, max-age=31536000, immutable",
      },
    });

    await cache.put(request, response.clone());
    return response;
  },
};

Questo replica il comportamento CDN di Pages, ma paghi per ogni cache miss (prima richiesta per file per PoP Cloudflare). Il CDN di Pages dispone di questo livello di memorizzazione nella cache senza costi aggiuntivi per richiesta.

Come eseguire la migrazione senza tempi di inattività

La sequenza meno rischiosa: in primo luogo, mantenere in esecuzione il progetto Pages. Crea nuovi lavoratori in parallelo. Configura percorsi che inviano traffico a nuovi lavoratori per percorsi specifici (a partire da quelli a rischio più basso, come webhook o percorsi amministrativi). Convalidare il comportamento in produzione con traffico reale prima di spostare i percorsi principali. Solo allora disattivare le funzioni delle pagine corrispondenti.

Per il frontend, non eseguire la migrazione delle risorse di Pages a R2 finché non sei sicuro che il costo aggiuntivo rientri nel budget del progetto. In molti casi, l’architettura ibrida – Pagine per frontend e asset, Worker per lavori asincroni e servizi specializzati – è più economica e altrettanto flessibile di una migrazione completa.

Cosa risolve davvero la migrazione

Trigger Cron, Worker multipli con routing granulare, staging con ambienti completamente isolati: questi i veri problemi che giustificano la migrazione. Se stai eseguendo la migrazione per un altro motivo, vale la pena verificare di non scambiare una limitazione con un costo più elevato.

La flessibilità dei lavoratori ha un prezzo operativo concreto: si presuppone la pipeline CI, la distribuzione in anteprima e il costo di gestione delle risorse statiche. Per i servizi backend puri senza risorse significative, questo costo è basso. Per le applicazioni con un frontend pesante e un volume elevato di traffico statico, può essere sostanziale.