Cosa fanno solo i Lavoratori, cosa fanno solo le Pagine e dove i due si incontrano

La documentazione della piattaforma tende a descrivere ciascun prodotto isolatamente, dalla migliore angolazione possibile. Ciò crea una lettura in cui Workers sembra più potente di Pages e Pages sembra più semplice di Workers. Nessuna delle due letture è corretta. Hanno capacità davvero uniche in ogni direzione e un'ampia zona di sovrapposizione in cui la differenza sta solo nel modello di implementazione.

Ciò che hanno solo i Lavoratori

I trigger cron sono la primitiva più rilevante che non esiste in Pages. In wrangler.toml:

[triggers]
crons = ["0 3 * * *", "*/15 * * * *"]

Questo registra due cron: uno alle 3 del mattino ogni giorno, un altro ogni 15 minuti. Il gestore corrispondente è il metodo scheduled dell'oggetto esportato dal Worker. Pages non ha questa primitiva. Non è una limitazione di runtime: è una decisione sul prodotto. Se hai bisogno di esecuzione periodica, si tratta di un lavoratore freelance.

I consumatori della coda operano in modo simile. Cloudflare Queues ti consente di mettere in coda i messaggi e di elaborarli in modo asincrono. Il consumatore - il lavoratore che legge dalla coda - è configurato a wrangler.toml con [[queues.consumers]]. Le funzioni delle pagine non possono essere consumatori di coda; può pubblicare messaggi nelle code solo tramite associazione.

I lavoratori e-mail ricevono i messaggi di posta elettronica direttamente. Configura un percorso email in Cloudflare in modo che punti a un lavoratore e il lavoratore riceve l'email come oggetto con mittente, destinatario, intestazioni e corpo. Ciò ti consente di elaborare i mancati recapiti, analizzare le ricevute delle fatture o instradare le e-mail a code diverse, il tutto senza un proprio server di posta elettronica. Pages non supporta questo trigger.

Workers for Platforms è il meccanismo multi-tenancy in cui gli utenti SaaS possono distribuire i propri Worker all'interno dell'account dell'operatore. L'operatore utilizza un Dispatch Worker che riceve le richieste e le inoltra allo script del tenant corretto. È un'infrastruttura primitiva per piattaforme che necessitano di eseguire codice utente arbitrario con isolamento garantito. Esclusivo per i lavoratori.

I socket TCP (in beta) consentono connessioni TCP dirette da un Worker, utili per connettersi a database che non dispongono di un'API HTTP, come PostgreSQL o Redis senza Upstash. Ancora in evoluzione, ma senza equivalenti in Pages.

Gli allarmi per oggetti durevoli meritano una menzione separata dagli oggetti durevoli in generale. I DO funzionano in entrambi, ma gli allarmi (timer che attivano un DO specifico in un momento definito) sono una primitiva di pianificazione che integra i trigger cron per i casi con stato per entità (pianificazione di un promemoria per utente, ad esempio). Disponibile in entrambi i runtime, ma l'orchestrazione normalmente inizia da un lavoratore con un cron o un trigger di coda.

Ciò che ha solo Pages

L'hosting di risorse statiche a costo zero per richiesta è la funzionalità più sottovalutata di Pages e la più costosa da replicare al di fuori di Pages. Quando distribuisci un progetto Pages, i file statici (HTML, CSS, JavaScript, immagini, caratteri) vengono distribuiti tramite la CDN globale di Cloudflare. Le richieste per queste risorse non passano attraverso il runtime di Workers: vengono servite direttamente dal perimetro della CDN, senza attivare alcuna logica di elaborazione, senza contare come un'invocazione, senza costi per richiesta oltre il piano di Pages.

Il piano gratuito di Pages include richieste CDN illimitate. Il piano a pagamento costa $ 20 al mese e aggiunge 5.000 build al mese e fino a 5 build simultanee. Per un sito con decine di milioni di visualizzazioni di pagina mensili, questa mancanza di costo per richiesta statica rappresenta un vantaggio di fatturazione significativo rispetto a qualsiasi architettura basata sui Workers puri.

L'anteprima delle distribuzioni automatiche per ramo è la seconda differenza. Ogni push a un ramo non principale genera un URL univoco nel formato hash-branch.seuprojeto.pages.dev, con risorse e funzioni che funzionano insieme. Nessuna configurazione aggiuntiva, nessuno script CI da scrivere. I lavoratori non lo replicano in modo nativo: è necessario impostare manualmente il flusso di "distribuzione del ramo" nel tuo elemento della configurazione.

Anche la pipeline di creazione integrata è unica. Pages rileva il framework (Next.js, Astro, SvelteKit, Nuxt, Hugo, Gatsby), configura le impostazioni predefinite di compilazione ed esegue il processo di compilazione in un ambiente isolato a ogni push. Per Workers, la compilazione è responsabilità del tuo CI, che è più flessibile, ma significa più configurazione da mantenere.

Le convenzioni _redirects e _headers consentono di configurare reindirizzamenti e intestazioni HTTP per risorse statiche tramite file di testo normale nella radice del progetto, senza codice. Utile per le migrazioni di URL, HSTS, policy di sicurezza dei contenuti e intestazioni della cache. I lavoratori possono implementare lo stesso con il codice, ma è più dettagliato.

Cosa hanno in comune i due

Il runtime V8 è identico. I limiti sono gli stessi: 128 MB di memoria (hard), 10 MB di script compresso sul piano a pagamento, 30 secondi di CPU per richiesta, 1.000 sottorichieste per invocazione. Qualsiasi codice eseguito in Workers viene eseguito in Pages Functions senza modifiche.

I data binding sono condivisi: D1 (SQLite all'edge), KV (valore-chiave distribuito), R2 (archiviazione di oggetti), oggetti durevoli (stato di coerenza di coordinazione), AI (inferenza del modello all'edge). È possibile avere accesso a un database D1 sia da Pages Functions che da un lavoratore autonomo configurato sullo stesso wrangler.toml con l'associazione che punta allo stesso ID database.

I collegamenti ai servizi funzionano in entrambi i modi: una funzione di pagine può chiamare un lavoratore autonomo direttamente tramite il collegamento interno, senza latenza della rete pubblica. Un Lavoratore può chiamare un altro Lavoratore. La chiamata è un normale fetch() contro il collegamento, ma instradata internamente sulla rete Cloudflare.

L'architettura che li utilizza ciascuno al posto giusto

Il modello che emerge dai progetti che utilizzano correttamente Workers e Pages ha tre livelli. Il primo è il progetto Pages: serve la SPA o il sito web generato dalla build, con risorse statiche sulla CDN senza alcun costo per richiesta. I percorsi API sono in /functions/api/ — Funzioni di pagina co-localizzate con il frontend, con anteprima del ramo inclusa, che accede a D1 e KV per i dati dell'applicazione.

Il secondo livello sono i Worker per i lavori asincroni: script autonomi con trigger cron per l'elaborazione pianificata, Consumer della coda per il lavoro asincrono disaccoppiato dal percorso critico HTTP, Email Workers per l'elaborazione della posta elettronica. Questi lavoratori accedono alle stesse associazioni dati del progetto Pages: lo stesso database D1, lo stesso spazio dei nomi KV.

Il terzo livello è la comunicazione tra loro tramite Service Bindings. Una funzione Pages che necessita di un'elaborazione complessa chiama direttamente il lavoratore specializzato, senza HTTP esterno. Il Cron Worker che deve attivare una notifica può chiamare la funzione di invio delle pagine tramite Service Binding.

Questa architettura non è teorica. Questo è ciò che accade quando utilizzi ciascuna primitiva dove risolve il problema con costi operativi inferiori: CDN gratuito di Pages per le risorse, stesso runtime per l'API co-localizzata, Worker autonomi per i trigger che Pages non supporta.

La mappa decisionale

La domanda che organizza la decisione è: cosa innesca questo codice? Se si tratta di una richiesta HTTP e il codice convive con un frontend, Pages Functions. Se si tratta di una richiesta HTTP ma il progetto non ha un frontend - servizio API puro - Workers con configurazione in wrangler.toml. Se si tratta di qualcosa di diverso dall'HTTP (orario programmato, messaggio in coda, e-mail in arrivo), i lavoratori non hanno alternative.