Cuando trabajas con múltiples workers en Cloudflare, la forma en que se comunican entre sí marca una diferencia importante en rendimiento y latencia. Entender cómo funcionan los service bindings y cómo organizar tu proyecto te permitirá construir arquitecturas más eficientes dentro del ecosistema de Cloudflare.
¿Qué son los bindings y cómo se configuran en Cloudflare Workers?
Dentro de cada worker desplegado, Cloudflare ofrece una sección dedicada a los bindings, que son conexiones entre el worker y otros recursos o servicios. Es posible configurarlos de dos maneras: de forma automática a través del archivo Wrangler o directamente desde la interfaz gráfica de Cloudflare [0:10].
Un detalle valioso es que cada producto de Cloudflare incluye enlaces directos a su documentación. Tomarse el tiempo de revisarla siempre aporta contexto adicional sobre las capacidades disponibles.
Al agregar un nuevo binding desde la interfaz, aparecen todas las opciones disponibles. Entre ellas se encuentra el de Secrets Store, que ya estaba configurado previamente en el proyecto, junto con una pieza de código de ejemplo que muestra cómo utilizarlo.
¿Cómo funciona un service binding entre workers?
El service binding fue el primer tipo de binding que Cloudflare lanzó. Su función es permitir que un worker llame directamente a otro worker sin pasar por una URL pública [0:50].
- Cuando agregas un service binding, puedes seleccionar cualquiera de los workers que ya están desplegados en tu cuenta.
- La comunicación ocurre dentro del mismo edge donde se ejecuta el worker, lo que reduce significativamente la latencia.
- No se añade carga extra de red, ya que la petición no sale del entorno de Cloudflare.
La recomendación de Cloudflare es clara: si la comunicación es de servidor a servidor, como una petición privada que maneja otro token u otra lógica interna, lo ideal es usar service bindings en lugar de llamadas HTTP tradicionales [1:10].
¿Cuándo usar una URL pública y cuándo un service binding?
Desde el front-end, cuando un usuario necesita comunicarse con la API, por ejemplo para registrar un email, es natural hacerlo a través de la URL pública. Esa petición se origina desde el cliente y necesita un punto de acceso público.
Pero en el caso de comunicación interna entre workers, el service binding es la opción recomendada. Cloudflare ha ido optimizando esta funcionalidad con el tiempo, incorporando soporte para RPC y gRPC [1:30]. Estas tecnologías permiten llamar a funciones remotas con una latencia mucho más baja y un consumo de recursos considerablemente más eficiente.
¿Cómo está organizada la estructura del proyecto?
Todo el progreso del proyecto está disponible en el repositorio compartido. Al revisar su estructura actual [1:50], se pueden identificar varios elementos clave:
- El servicio de email recién agregado.
- Una sección de documentación que incluye el MCP de Cloudflare, configurado para que el asistente de código genere soluciones siguiendo las mejores prácticas del ecosistema.
- Un archivo con los requisitos, la configuración inicial y las instrucciones para desarrollo local.
- Las variables de entorno con la nueva API key registrada.
¿Qué viene después con D1?
El README del proyecto ya anticipa el siguiente paso: agregar persistencia con D1 [2:20]. Se trata de la base de datos gestionada de Cloudflare, y en la próxima sesión se abordará qué tipo de motor utiliza, cuáles son sus límites y sus casos de uso principales.
Si has seguido el proyecto hasta este punto, tienes una base sólida con workers desplegados, bindings configurados y servicios comunicándose entre sí. Comparte en los comentarios qué tipo de arquitectura estás construyendo con Cloudflare Workers.
