Service binding frente a fetch externo

Puedes lograr que un Worker hable con otro de dos maneras que en el editor se parecen sospechosamente: darle al segundo una ruta pública y hacer fetch a su URL, o cablear un service binding e invocarlo por env. Ambas devuelven una respuesta; ambas caben en una línea. Pero no son variantes de lo mismo: difieren en naturaleza. Esta lección disecciona los tres ejes donde se separan —velocidad, seguridad y coste— y termina con la pregunta que todo ingeniero maduro se hace: ¿cuándo, pese a todo, el HTTP público sigue siendo lo correcto?

Más rápido: la red pública desaparece

Una llamada por URL, aunque el destino esté en el mismo centro de datos, se ve obligada a comportarse como si estuviera al otro lado del planeta. Resuelve un nombre por DNS. Abre una conexión y negocia TLS, con su ida y vuelta criptográfica. Cruza la pila de red pública. Y todo eso antes de que el otro Worker ejecute una sola línea. En una petición corta, ese preámbulo domina el tiempo total: el cómputo útil es un parpadeo comparado con el ritual de llegar hasta él.

Un service binding borra el preámbulo entero. La invocación no resuelve nombres ni negocia cifrado ni sale a la red: viaja por la infraestructura interna de Cloudflare, entre Workers coubicados. Lo que quedaba —el cómputo del Worker invocado— es lo único que pagas en tiempo, porque el trayecto para llegar a él se ha reducido a prácticamente nada.

Más seguro: no hay puerta pública que defender

Una URL pública es, por definición, alcanzable por todo el mundo. Eso te obliga a tratar a cada llamante como un potencial hostil: autenticar cada petición interna con un token, poner límites de tasa, vigilar que nadie descubra el endpoint y lo martillee. Has abierto una puerta a la calle solo para que dos habitaciones de tu propia casa se hablen, y ahora tienes que ponerle cerradura y guardia.

Un service binding no es direccionable desde fuera. El Worker invocado puede no tener ninguna ruta pública en absoluto: existe solo para ser llamado por los Workers que lo declaran. Eso es mínima autoridad aplicada a la topología: solo quien tiene el binding puede invocarlo, y ese permiso se otorga explícitamente en la configuración, no se defiende a golpe de token en cada petición.

Más barato: sin peaje de la red

El coste sigue a la física. Una llamada por URL es una petición externa de pleno derecho: consume ancho de banda, paga la terminación TLS, y en muchas arquitecturas cuenta como una salida a internet que se factura. Un service binding no cruza la red pública, así que ese peaje no se cobra. Conviene la honestidad: el Worker invocado se ejecuta y su cómputo se cuenta —no es gratis hacer trabajo—, pero el salto entre ambos no añade el coste de una petición externa. Pagas el trabajo, no el trayecto.

Cuándo el HTTP público sigue teniendo sentido

Nada de esto convierte al fetch externo en un error. Hay casos en que es exactamente lo que quieres. Si el destino no es tuyo —una API de terceros, un servicio en otra nube— no hay binding posible: hablas HTTP porque hablas con un extraño. Si el destino debe ser genuinamente público —un webhook, una API abierta a clientes que no controlas— su naturaleza es una URL. Y si necesitas el desacople total de dos sistemas que se despliegan, versionan y hasta se apagan sin coordinación alguna, la frontera dura de HTTP es una virtud, no un defecto.

flowchart TD
Q[A necesita llamar a B] --> D[B es tuyo y vive en Cloudflare]
D -->|si| BND[service binding]
D -->|no es tuyo o debe ser publico| HTTP[fetch a URL publica]
BND --> R1[sin red sin token barato]
HTTP --> R2[con red con auth facturable]
style BND fill:#a6e3a1,color:#11111b
style HTTP fill:#f9e2af,color:#11111b