Cloudflare Workers ti consente di eseguire codice backend all’edge, vicino ai tuoi utenti, senza gestire server. Per le API, questa combinazione di cold start quasi nulli, distribuzione globale e storage strettamente integrato rende Workers una piattaforma convincente nel 2026. Questa guida spiega come è strutturata un’API Cloudflare Workers e cosa la distingue da un backend tradizionale.

In breve

  • Cloudflare Workers esegue il tuo codice sulla rete globale di Cloudflare all’edge, così le richieste vengono servite vicino agli utenti con cold start quasi nulli
  • Un Worker gestisce le richieste in arrivo tramite un handler fetch; instradi in base a metodo e percorso e restituisci oggetti Response standard
  • I Workers si collegano direttamente allo storage: D1 (SQLite), KV (chiave-valore), R2 (object storage), Queues e Durable Objects
  • I Workers sono adatti ad API a bassa latenza e distribuite globalmente; usano un runtime leggero anziché un ambiente server completo, il che ne plasma la costruzione

Cosa rende diversi i Workers

Un’API tradizionale gira su un server (o un container) in una sola regione. Cloudflare Workers gira invece sulla rete globale di Cloudflare usando leggeri V8 isolates anziché container o macchine virtuali. Le conseguenze pratiche:

  • Cold start quasi nulli. Gli isolates si avviano quasi istantaneamente, evitando i ritardi da cold start comuni ad alcune piattaforme serverless.
  • Globale per impostazione predefinita. Il tuo codice gira vicino a ogni utente sulla rete di Cloudflare, riducendo la latenza senza che tu debba effettuare il deploy su più regioni.
  • Nessun server da gestire. Niente provisioning, patching o scaling; ci pensa la piattaforma.
  • Un runtime mirato. I Workers forniscono API web-standard (Fetch, Request/Response, Web Crypto, streams) anziché un sistema operativo server completo, con un layer di compatibilità Node.js per molte API Node. Progetti attorno agli standard del web.

La forma di un’API Cloudflare Workers

Al suo cuore, un Worker esporta un handler che riceve ogni richiesta:

1export default {
2  async fetch(request, env, ctx) {
3    const url = new URL(request.url);
4    if (request.method === "GET" && url.pathname === "/api/health") {
5      return Response.json({ status: "ok" });
6    }
7    return new Response("Not found", { status: 404 });
8  }
9};

Da qui costruisci:

  • Il routing in base a metodo HTTP e percorso (a mano per API piccole, o con un router leggero per quelle più grandi).
  • Il parsing delle richieste usando i metodi Request standard per JSON, dati di form e parametri di query.
  • Le risposte come oggetti Response standard, incluso Response.json().
  • I bindings disponibili sull’argomento env per raggiungere lo storage e altre risorse.

Collegare lo storage con i bindings

La vera forza di un’API Workers sta in quanto direttamente si collega ai dati:

  • D1 per un database SQLite serverless, ideale per dati relazionali. Vedi Cloudflare D1 .
  • KV per dati chiave-valore veloci e distribuiti globalmente, come configurazioni o cache.
  • R2 per l’object storage (file, immagini) senza costi di egress.
  • Queues per l’elaborazione asincrona in background.
  • Durable Objects per coordinamento con stato e coerenza dove ne hai bisogno.

I bindings vengono dichiarati nella tua configurazione e compaiono su env, così il tuo codice li richiama direttamente senza gestire stringhe di connessione o credenziali nel modo consueto.

Sviluppo e deployment

  • Wrangler, la CLI di Cloudflare, gestisce sviluppo locale, configurazione, secret e deployment.
  • Sviluppi contro un runtime locale che rispecchia la produzione, poi effettui il deploy globale con un solo comando.
  • I secret vengono gestiti tramite Wrangler anziché essere committati nel codice.

Quando i Workers sono la scelta giusta

I Workers sono un’ottima scelta per API a bassa latenza e distribuite globalmente, webhook, middleware di edge e servizi che traggono vantaggio dall’esecuzione vicino agli utenti. Sono meno adatti a carichi che richiedono processi a lunga durata, calcolo intensivo su CPU oltre il modello di richiesta, o un runtime di linguaggio specifico che la piattaforma non supporta. Per un confronto più ampio sul compute, vedi Cloudflare Workers vs AWS Lambda .

Un esempio concreto: l’API AI Code Review è costruita su Cloudflare Workers, gira all’edge in tutto il mondo senza cold start per restituire risultati rapidi e strutturati, esattamente il tipo di API a bassa latenza in cui i Workers eccellono.

Punti chiave

  • Un’API Cloudflare Workers gira all’edge con cold start quasi nulli e distribuzione globale, senza server da gestire.
  • Un Worker gestisce le richieste tramite un handler fetch; instradi in base a metodo e percorso e restituisci oggetti Response standard.
  • I bindings collegano la tua API direttamente a D1, KV, R2, Queues e Durable Objects.
  • I Workers sono adatti ad API a bassa latenza e distribuite globalmente; il loro runtime web-standard mirato ne plasma la costruzione.

Costruisci la tua API edge con gli esperti

Progettare un’API serverless che sfrutti bene l’edge (routing, binding di storage e runtime web-standard) trae vantaggio dall’esperienza sulla piattaforma. Esplora i prodotti e strumenti di Mecanik per esempi costruiti su Cloudflare, e scopri come il confronto Cloudflare Pages vs Workers ti aiuta a scegliere il servizio Cloudflare giusto per il tuo progetto.

Domande frequenti (FAQ)

Cos’è un’API Cloudflare Workers? È un’API backend che gira come codice sulla rete edge globale di Cloudflare anziché su un server tradizionale. Un Worker gestisce le richieste HTTP tramite un handler fetch e può collegarsi direttamente allo storage come D1, KV e R2, servendo le richieste vicino agli utenti con cold start quasi nulli.

I Cloudflare Workers hanno cold start? Hanno cold start quasi nulli perché girano su leggeri V8 isolates che si avviano quasi istantaneamente, anziché avviare container o macchine virtuali. Questo è uno dei principali vantaggi dei Workers per le API sensibili alla latenza.

Posso usare un database con Cloudflare Workers? Sì. I Workers si collegano direttamente a D1 (SQLite serverless) per dati relazionali, KV per dati chiave-valore, R2 per object storage, oltre a Queues e Durable Objects. I bindings compaiono sull’argomento env così il tuo codice vi accede direttamente.

Quale linguaggio usano i Cloudflare Workers? Principalmente JavaScript e TypeScript, e WebAssembly per altri linguaggi. I Workers forniscono API web-standard (Fetch, Request/Response, Web Crypto) con un layer di compatibilità Node.js per molte API Node, così costruisci attorno agli standard del web anziché a un runtime server completo.

Quando dovrei usare Cloudflare Workers per un’API? Usa i Workers per API a bassa latenza e distribuite globalmente, webhook e middleware di edge che traggono vantaggio dall’esecuzione vicino agli utenti con scaling istantaneo. Sono meno adatti a processi a lunga durata o a lavoro intensivo su CPU al di fuori del modello di richiesta.