Desarrollo de funciones serverless con Cloudflare Workers

Cloudflare Workers es la plataforma serverless de Cloudflare: permite ejecutar código propio en su red global sin administrar servidores. Serverless significa que vos no contratás ni mantenés una máquina; pagás y escalás según las solicitudes que el código atiende. Dentro de nuestro trabajo con Cloudflare, los Workers son la herramienta para agregar lógica justo en el borde de la red, antes de que una visita llegue a tu sitio.

Algunos desarrollos que hacemos con Workers:

• Redirecciones a gran escala después de una migración, con miles de URLs viejas apuntando a las nuevas.
• Receptores de webhooks que reciben avisos de pasarelas de pago o plataformas externas y los reenvían de forma segura.
• APIs livianas para formularios, consultas de stock o cotizaciones, sin depender del servidor principal.
• Intermediarios para APIs externas que ocultan tus claves y agregan caché a las respuestas.
• Personalización por ubicación, como mostrar precios o contenidos según el país del visitante.
• Tareas programadas con Cron Triggers, por ejemplo limpiar datos o generar un reporte diario.

Un Worker tiene sentido cuando la tarea es acotada, tiene que responder rápido y no justifica un servidor dedicado. También cuando necesitás que algo siga funcionando aunque tu aplicación principal esté caída, como la recepción de un aviso de pago.

No es la mejor opción para procesos largos o pesados, como convertir videos, ni para aplicaciones que dependen de un sistema de archivos local. En esos casos conviene un contenedor o una función en Google Cloud.

1. Definimos el alcance: qué solicitudes atiende, qué datos usa y qué responde en caso de error.
2. Programamos en TypeScript con Wrangler, la herramienta oficial de Cloudflare, y lo probamos localmente.
3. Conectamos los recursos que necesita mediante bindings, que son las conexiones del Worker con otros servicios de Cloudflare, como KV, colas o el almacenamiento con R2 y D1.
4. Publicamos en un entorno de pruebas y después en producción, con despliegue automático desde el repositorio.
5. Activamos los registros de ejecución para ver errores y tiempos de respuesta.

Si tu proyecto ya vive en Google Cloud o Firebase, comparamos esta opción con Cloud Functions antes de decidir.

• El código del Worker en un repositorio a tu nombre, con instrucciones para publicarlo.
• Entornos de prueba y producción separados, cada uno con sus secretos.
• Los registros de ejecución activos para diagnosticar problemas.
• Documentación de las rutas, los datos que usa y cómo modificarlo.