Tipos de bindings

Todos los bindings comparten el mismo modelo de acceso —los declaras y aparecen en env—, pero no todos conceden el mismo poder. Uno te da un almacén de claves y valores; otro, una base de datos SQL; otro, la capacidad de invocar a otro Worker o a un modelo de IA. Conocer el catálogo no es memorizar una lista de productos, sino aprender a mapear cada necesidad de tu aplicación a la capacidad mínima que la satisface.

Almacenamiento: cuatro formas de recordar

El grupo más numeroso concede persistencia, pero cada miembro almacena una forma distinta de dato y expone un cliente distinto en env. Elegir bien empieza por reconocer qué modela cada uno.

La distinción de fondo es el modelo de consistencia. KV sacrifica consistencia inmediata por velocidad global; D1 te da transacciones SQL; y un Durable Object es la herramienta cuando necesitas que una entidad —una sala de chat, un contador, una sesión— tenga un dueño único que serialice sus cambios sin condiciones de carrera.

Mensajería y cómputo entre Workers

No todos los bindings apuntan a un almacén. Dos de ellos conceden la capacidad de comunicar piezas de cómputo entre sí, dentro de la red de Cloudflare y sin pasar por la internet pública.

Un binding a Queues te convierte en productor de una cola: env.MI_COLA.send(mensaje) encola trabajo que otro Worker —el consumidor— procesará después, de forma asíncrona y con reintentos. Es el desacople clásico entre quien pide y quien ejecuta.

Un service binding te da una referencia a otro Worker y te deja invocarlo directamente, como si sus métodos fueran locales. La llamada no sale a la red pública: viaja por la infraestructura interna, sin latencia de ida y vuelta por internet ni necesidad de autenticar una API.

export default {
  async fetch(request, env, ctx): Promise<Response> {
    // productor de una cola: encola y sigue
    await env.MI_COLA.send({ tipo: 'email', a: 'ada@ejemplo.com' });

    // service binding: invoca a otro Worker sin salir a internet
    const respuesta = await env.AUTH.fetch(request);
    return respuesta;
  },
} satisfies ExportedHandler<Env>;

Inteligencia y configuración

El último grupo mezcla lo más nuevo de la plataforma con lo más básico. Comparten que también son capacidades declaradas, aunque su forma sea muy distinta entre sí.

La inteligencia merece verse en código, porque es donde el modelo de acceso más sorprende: pides inferencia o una búsqueda vectorial con el mismo gesto con el que leerías una clave de configuración.

// pedir a un modelo y consultar un indice se hacen como cualquier binding
const salida = await env.AI.run('@cf/meta/llama-3.1-8b-instruct', {
  prompt: 'Resume el edge en una frase',
});
const vecinos = await env.VEC.query(vectorConsulta, { topK: 3 });

Secretos y variables son el recordatorio de que incluso una simple cadena de configuración entra por el mismo conducto que un cliente de base de datos. La diferencia entre ambos es la sensibilidad y el lugar donde viven: la variable es pública y va en la configuración; el secreto es cifrado y se sube por un canal aparte para que nunca aparezca en el repositorio.

flowchart TD
ENV[env] --> ALM[Almacenamiento]
ENV --> MSG[Mensajeria y computo]
ENV --> IA[Inteligencia]
ENV --> CFG[Configuracion]
ALM --> A1[KV R2 D1 Durable Objects]
MSG --> M1[Queues y service bindings]
IA --> I1[Workers AI y Vectorize]
CFG --> C1[secretos y variables]
style ENV fill:#89b4fa,color:#11111b
style A1 fill:#a6e3a1,color:#11111b
style M1 fill:#a6e3a1,color:#11111b
style I1 fill:#a6e3a1,color:#11111b
style C1 fill:#a6e3a1,color:#11111b