Desarrollo con Cloudflare Workers para aplicaciones edge rápidas y conformes

Los Workers se ejecutan en isolates de V8 en lugar de contenedores por solicitud, por lo que arrancan en mucho menos de un milisegundo, sin penalización de arranque en frío, y se ejecutan en más de 300 ubicaciones cercanas a los usuarios. Lambda ofrece un entorno completo de Node.js/runtime y ventanas de ejecución más largas, pero con arranques en frío más pesados; Vercel Functions se acercan más a los Workers, pero con otra plataforma y otro modelo de precios. Le ayudamos a elegir por carga de trabajo — Workers para la lógica de edge crítica en latencia y funciones tradicionales para cómputo pesado o de larga duración.

Use KV para configuración y caché de baja latencia y mucha lectura que toleren la consistencia eventual; D1 para datos relacionales consultables con SQL y una región de origen definida; Durable Objects para estado por entidad con consistencia fuerte, coordinación, bloqueos y websockets; y R2 para almacenamiento de objetos y archivos sin cargos de salida. La mayoría de las aplicaciones reales combinan varios. Asignamos cada necesidad de datos a la primitiva adecuada en el momento del diseño para evitar lecturas obsoletas y sorpresas de residencia.

En parte, y hay que diseñarlo para ello. Data Localisation Suite y los EU Regional Services de Cloudflare mantienen el tráfico, la inspección y la terminación TLS dentro de la UE, y D1/R2 admiten ubicación regional. KV se replica globalmente, así que dirigimos los datos personales realmente regulados a D1 o R2 de la región o a un backend de la UE en lugar de depender de KV. Construimos los límites de residencia de forma explícita y documentamos los flujos de datos.

Los Workers limitan el tiempo de CPU por solicitud, carecen de buena parte de la biblioteca estándar de Node.js y del acceso al sistema de archivos, y no son adecuados para tareas de larga duración o de cómputo intensivo dentro de una sola solicitud. También se aplican límites de memoria y de subsolicitudes. Diseñamos en torno a ello — delegando el trabajo pesado o con estado a Queues, Durable Objects o un backend dedicado — para que el edge se ocupe de aquello en lo que es bueno.

Evite los Workers como única capa para el procesamiento por lotes intensivo en CPU, las cargas grandes en memoria, el software que necesita Node.js completo o binarios nativos, o los datos regulados con requisitos estrictos de residencia y auditoría que un backend dedicado y conforme atiende mejor. Son una excelente capa de edge y de orquestación, pero no un sustituto directo de cualquier servidor. Somos francos cuando una arquitectura híbrida o tradicional encaja mejor.

Pages es la plataforma de despliegue para sitios front-end y full-stack — activos estáticos, SSR de frameworks y despliegues de vista previa —, mientras que Workers son las funciones serverless que ejecutan su lógica de backend. Los proyectos modernos de Pages se ejecutan sobre Workers por debajo, así que solemos usar Pages para la superficie de la aplicación y Workers, con bindings de KV/D1/R2/Durable Objects, para las APIs y los datos. Son complementarios, no competidores.

La seguridad está tanto delante como dentro del Worker. El WAF de Cloudflare, la mitigación de DDoS, Bot Management y la limitación de tasa filtran los abusos antes de que las solicitudes lleguen a su código, mientras que el propio Worker impone la autenticación, la validación de entradas y las cabeceras CSP/HSTS reforzadas. Las superficies de administración e internas quedan tras las políticas zero-trust de Cloudflare Access, y los secretos viven en bindings de entorno gestionados con Wrangler — nunca en el código fuente.