Cloudflare Workers explicado sin buzzwords

Un Cloudflare Worker es código serverless que responde requests en la red global de Cloudflare.

La forma más simple de pensarlo:

request -> Worker -> response

Escribes un handler, casi siempre fetch(). Cuando llega un request a tu dominio o a una ruta asociada, Cloudflare ejecuta ese código y espera una Response.

No estás administrando una VM. No estás levantando un Express en un VPS. No estás cuidando un proceso Node que se cae a las 3 a.m.

Estás desplegando una pieza de código que la plataforma puede ejecutar por ti.

Qué significa “edge” (y qué no)

“Edge” se traduce como “borde”, pero casi nadie lo usa así en una conversación técnica.

En este contexto:

ubicaciones de red más cercanas al usuario que un backend central tradicional.

Si tu backend vive solo en us-east, un usuario en Colombia, México o Chile puede pagar latencia de ida y vuelta en cada request importante. Con Workers, parte de tu lógica HTTP puede correr en la red global de Cloudflare.

Eso no significa que todo sea mágicamente más rápido o mejor diseñado. Significa que tienes otra capa donde poner lógica de entrada.

No digas:

“Tu backend empieza en el edge.”

Mejor:

“La primera capa de tu API puede correr en la red de Cloudflare, normalmente más cerca del usuario que tu backend central.”

Qué problema resuelve (y cuál no)

Muchas apps empiezan así y está bien:

usuario -> CDN -> backend central -> base de datos -> respuesta

No hay que tirar ese modelo a la basura.

Pero hay requests que no necesitan viajar hasta el backend principal:

redirect por idioma o país
webhook pequeño
/api/health
middleware de auth ligera
normalización de headers
proxy hacia otro servicio
validación básica antes de delegar

Workers sirve para poner esa lógica cerca de la entrada.

No lo pienses como “reemplazo mi backend completo”.

Piensa:

tengo una capa HTTP programable antes, durante o alrededor de mi backend.

El Worker mínimo

export default {
  async fetch(request, env, ctx): Promise<Response> {
    return Response.json({
      ok: true,
      message: "Hola desde Workers",
      path: new URL(request.url).pathname,
    });
  },
} satisfies ExportedHandler<Env>;

Tres piezas:

request — lo que llegó del usuario
env — bindings y configuración
ctx — contexto de ejecución (ctx.waitUntil(), etc.)

Para el primer día, con esto basta:

fetch recibe un Request y devuelve una Response.

Dónde encaja en la arquitectura

cliente -> Worker -> recurso o servicio

Ese recurso puede ser otro backend, R2, D1, KV, una Queue, un Durable Object, AI Gateway u otro Worker. Cuando conectas esos recursos, entran los bindings.

Por eso Workers no se aprende solo como “una función”. Se aprende como puerta de entrada a la plataforma.

Ejemplo: una ruta concreta

export default {
  async fetch(request, env, ctx): Promise<Response> {
    const url = new URL(request.url);

    if (url.pathname === "/api/health") {
      return Response.json({
        status: "ok",
        service: "pricing-api",
      });
    }

    return new Response("Not found", { status: 404 });
  },
} satisfies ExportedHandler<Env>;

Este ejemplo no intenta ser una app completa. Ese es el punto: Workers brilla resolviendo piezas concretas de la capa HTTP.

Cuándo usaría Workers

Usaría Workers para:

endpoints pequeños
webhooks
redirects inteligentes
middleware
APIs para frontends
proxy o routing entre servicios
validaciones rápidas
producir mensajes hacia una Queue
iniciar un Workflow
llamar AI Gateway con control adicional

Cuándo no metería todo ahí

Tendría cuidado si:

el proceso dura mucho
necesitas varios pasos con retries
quieres estado fuerte por usuario, sala o documento
el trabajo es pesado (imágenes, batch, etc.)
estás mezclando demasiadas responsabilidades en un solo handler

Dentro del mismo ecosistema:

Necesitas	Mira
Estado por entidad	Durable Objects
Trabajo async	Queues
Proceso multi-paso durable	Workflows
Object storage	R2
SQL	D1
Key-value simple	KV

Error común: el Worker gigante

El primer Worker empieza limpio. Luego le agregan auth, emails, imágenes, IA, analytics, CRM y coordinación de sesiones. De pronto tienes una función imposible de depurar.

Mejor modelo mental:

Worker = entrada HTTP
Queue = trabajo async
Durable Object = estado por entidad
Workflow = proceso largo con pasos
R2 / D1 / KV = almacenamiento según el caso

Antes de producción

Qué rutas atiende.
Qué debe responder de inmediato.
Qué puede ir a una Queue.
Qué recursos aparecen en env.
Qué logs necesitas para debug.
Cómo separas dev, staging y producción.
Qué pasa si falla una dependencia.

Un Worker pequeño puede ser simple. Un sistema de Workers necesita diseño.

La frase para recordar

Request -> fetch() -> Response

Workers es la puerta. La arquitectura aparece cuando decides qué debe hacer esa puerta y qué debe delegar.

Serie Cloudflare para builders: Workers · Bindings · Durable Objects · Queues

Docs: Workers · How Workers works · Runtime APIs · Bindings