Cloudflare Workers: qué son y cuándo conviene usarlos

Un Cloudflare Worker es una función en JavaScript que se ejecuta en la red de Cloudflare, cerca de quien hace la petición, sin que tengas un servidor. La escribes, la subes y Cloudflare la ejecuta cada vez que llega una petición a la ruta que le asignaste.

Una aclaración antes de seguir: codegea.com no usa Workers (de Cloudflare usamos DNS y R2). Este artículo es de criterio, apoyado en lo que dice la documentación de Cloudflare, para que sepas cuándo tiene sentido y cuándo no.

Cómo es un Worker

Lo mínimo que puede ser:

export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (url.pathname === '/oferta-vieja') {
      return Response.redirect('https://tudominio.com/oferta', 301);
    }

    return fetch(request);
  },
};

Si la ruta es /oferta-vieja, responde con una redirección 301. Si no, deja pasar la petición hacia tu sitio. Se despliega con la herramienta de línea de comandos de Cloudflare, wrangler:

npx wrangler deploy

Para qué sirven bien

• Redirects y reescrituras antes de que la petición llegue a tu servidor. Útil cuando tienes cientos de URLs antiguas tras una migración.
• Cabeceras de seguridad o de caché añadidas a cada respuesta, sin tocar la aplicación.
• APIs pequeñas: un endpoint que valida algo, consulta un servicio y devuelve JSON.
• Proteger o transformar archivos de un bucket R2: comprobar una firma, redimensionar o servir con reglas propias.
• Tareas programadas (Cron Triggers): limpiar datos, lanzar un aviso, refrescar una caché.

Sus límites, que son reales

La documentación de Cloudflare lista restricciones que conviene tener presentes:

• Tiempo de CPU. En el plan gratis, 10 ms por petición. En el de pago, el límite por defecto es mucho mayor. El tiempo de espera de red o de otras llamadas no cuenta como CPU.
• Memoria: 128 MB por instancia. Con archivos grandes hay que trabajar en flujo (streaming), no cargarlos enteros.
• Subpeticiones. Cada fetch() o llamada a R2, KV o D1 cuenta, y hay un tope por invocación (50 en el plan gratis).
• Peticiones diarias. En el plan gratis hay un máximo por día.
• Sin servidor tradicional. No es Node.js completo; no todas las librerías funcionan.

Estos números cambian, así que revísalos en la documentación vigente antes de diseñar algo que dependa de ellos.

Cuándo no usarlos

• Trabajo pesado de CPU: procesar imágenes grandes, generar PDFs complejos, cálculos largos. Si pasa del límite, Cloudflare lo corta.
• Tareas largas: las programadas y las colas tienen un máximo de tiempo.
• Aplicaciones que dependen de librerías de Node que no se ejecutan en este entorno.
• Cuando ya tienes dónde ejecutar el código. Si tu sitio está en Vercel, sus funciones resuelven casi todo lo que haría un Worker, sin añadir otra plataforma. Por eso en nuestro sitio las rutas de API van en Next.js.

Workers y el resto de la serie

Los Workers se llevan bien con R2 y con D1, la base de datos SQLite de Cloudflare, que conectan como bindings. Si te interesa esa ruta, hablamos de ella en qué bases de datos soporta Payload CMS, y de R2 en R2 vs S3.

Regla práctica

Piensa en un Worker como el pegamento ligero en el borde: redirigir, vigilar, transformar, avisar. Si lo que necesitas es el cerebro de tu aplicación, un servidor o funciones de tu plataforma habitual suelen ser mejor punto de partida.