Qué es un service binding

Tarde o temprano tu aplicación deja de ser un solo Worker. Aparece un segundo —uno valida sesiones, otro redimensiona imágenes— y surge la pregunta inevitable: ¿cómo hace el primero para hablar con el segundo? El reflejo heredado de los microservicios es publicar el segundo con una URL y llamarlo por HTTP. Cloudflare ofrece otra vía, más íntima y mucho más barata: un service binding, que enchufa un Worker a otro directamente, sin que la llamada llegue a salir a la internet pública.

El problema: dos Workers que se necesitan

A medida que una aplicación crece, dejas de meterlo todo en un Worker. El que lo hacía todo se parte en un Worker para la API pública y otro que solo verifica identidad. Y en cuanto existen dos, el primero necesita hablar con el segundo. El instinto que traes del mundo de los microservicios es darle al Worker de autenticación una URL pública y llamarla por HTTP desde el otro.

Funciona, pero fíjate en lo que obligas a hacer a esa llamada. Una petición entre dos piezas que son tuyas, que viven en la misma red y a menudo en la misma máquina, se ve forzada a recorrer el mismo camino que la de un desconocido cualquiera de internet: resolver un nombre por DNS, abrir un canal TLS con su saludo criptográfico, cruzar la red pública, autenticarse contra la API y volver. Pagas el peaje completo de la red pública por una conversación doméstica.

Un binding que apunta a cómputo

Un service binding es, como todo binding, una capacidad declarada que aparece en env. Pero donde un binding de KV o de D1 apunta a un almacén, un service binding apunta a otro Worker. Lo declaras en wrangler.jsonc:

{
  "name": "api",
  "services": [
    { "binding": "AUTH", "service": "auth-worker" }
  ]
}

A partir de ahí, env.AUTH es una referencia viva al otro Worker. La forma más simple de usarlo calca el modelo de petición y respuesta que ya conoces: le entregas un Request y te devuelve un Response, igual que un fetch, salvo que el destino es un Worker cableado por nombre y no una URL.

export default {
  async fetch(request, env, ctx): Promise<Response> {
    // env.AUTH es otro Worker, invocado sin URL ni credenciales
    const veredicto = await env.AUTH.fetch(request);
    if (veredicto.status !== 200) {
      return new Response("no autorizado", { status: 401 });
    }
    return new Response("recurso protegido");
  },
} satisfies ExportedHandler<Env>;

Fíjate en lo que no aparece: ninguna URL. No escribiste la dirección de auth-worker; nombraste una capacidad, AUTH, y la plataforma la resolvió a un Worker concreto. A cuál apunta se decide en la configuración, no en el código —la misma indirección que viste en todos los demás bindings—.

La llamada que nunca sale a internet

Aquí está el corazón del asunto. Cuando llamas por una URL pública, la petición sale del edificio de Cloudflare, resuelve DNS, negocia TLS, viaja por internet y regresa —aunque el Worker de destino viva en el mismísimo centro de datos que el que llama—. Un service binding colapsa ese recorrido: la invocación se queda dentro de la infraestructura de Cloudflare, sin DNS, sin apretón de manos TLS, sin viaje de ida y vuelta por la red pública. Los dos Workers se componen como funciones de un mismo programa, no como servicios remotos que se buscan a ciegas.

Conviene ser honesto con la expresión latencia cero: no es que el tiempo desaparezca por arte de magia, sino que el sumando que domina en una petición corta —el saludo TLS y el ida y vuelta por la red— se reduce a prácticamente nada porque los dos Workers están coubicados. Lo que pagabas antes no era el cómputo del otro Worker, sino el trayecto para llegar a él; y ese trayecto es justo lo que el binding elimina.

flowchart LR
A1[Worker A por URL] --> DNS[resolver DNS] --> TLS[saludo TLS] --> NET[red publica] --> B1[Worker B]
A2[Worker A por binding] --> BND[binding AUTH] --> B2[Worker B]
style NET fill:#f9e2af,color:#11111b
style BND fill:#a6e3a1,color:#11111b