Workers y Containers: el front y el backend pesado

Un Container casi nunca se usa solo: se usa detrás de un Worker. El Worker es el front —barato, instantáneo, desplegado en toda la red— y el Container es el backend pesado —potente pero escaso, facturado por el tiempo que corre—. El arte de esta arquitectura está en dónde trazas la línea: cuánto trabajo resuelve el front antes de molestar al backend, y qué porción mínima merece de verdad descender a un sistema operativo entero. Dominar ese reparto es la diferencia entre una app que aprovecha el edge y otra que arrastra un servidor caro disfrazado.

Dos capas, dos economías

La tentación es ver el Worker y el Container como dos formas de ejecutar código. Son algo más incómodo y más útil: dos economías distintas. El Worker corre en cientos de ubicaciones, arranca en cero milisegundos y se factura por petición y por milisegundos de CPU; su coste marginal es casi nulo, pero está acotado en potencia. El Container ofrece un sistema operativo completo con CPU, memoria y disco de sobra, pero es un recurso escaso —limitado por max_instances—, se despliega en menos ubicaciones y se factura por el tiempo que permanece vivo, con una penalización de segundos al despertar.

De esa asimetría sale una regla económica, no solo técnica: cada milisegundo de trabajo que retienes en el Worker es prácticamente gratis e instantáneo; cada milisegundo que empujas al Container cuesta tiempo de ejecución y arriesga el coste de despertarlo. La arquitectura, entonces, es un problema de optimización: maximizar el trabajo en la capa barata y global, minimizar el núcleo irreducible que baja a la capa cara.

El Worker enruta, el Container ejecuta

El Container nunca se expone al público: la única puerta es el Worker. Eso convierte al Worker en el cerebro y al Container en el músculo. El cerebro hace todo lo que un isolate sabe hacer —validar un token, aplicar límites de tasa, comprobar la caché, dar forma a la respuesta, enrutar— y solo delega la operación genuinamente pesada.

import { Container, getContainer } from "@cloudflare/containers";

export class PdfContainer extends Container {
  defaultPort = 8080;
  sleepAfter = "5m";
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // 1. El front barato hace todo lo que un isolate puede hacer
    const usuario = await autenticar(request, env);
    if (!usuario) return new Response("No autorizado", { status: 401 });

    const cacheada = await caches.default.match(request);
    if (cacheada) return cacheada;   // ni despertamos el contenedor

    // 2. Solo el trabajo irreducible baja al backend pesado
    const instancia = getContainer(env.PDF, usuario.tenantId);
    const respuesta = await instancia.fetch(request);

    // 3. El front vuelve a mandar: cachea la salida cara
    if (respuesta.ok) {
      await caches.default.put(request, respuesta.clone());
    }
    return respuesta;
  },
};

Observa las dos salidas tempranas. Una petición sin autorizar y una que acierta en caché se resuelven sin tocar el Container: son gratis e instantáneas. Solo cuando el trabajo es real —generar el PDF— el Worker llama a getContainer con un id (aquí el del inquilino) y delega. Ese id da enrutado pegajoso: todas las peticiones de un mismo inquilino aterrizan en su propia instancia, lo que aísla clientes y aprovecha el estado caliente del contenedor.

flowchart TD
R[Peticion] --> W[Worker front]
W -->|no autenticado| X[401 sin tocar el backend]
W -->|acierto en cache| HIT[Responder desde cache]
W -->|trabajo real| C[getContainer y delegar]
C --> P[Container pesado ejecuta]
P --> W
style W fill:#89b4fa,color:#11111b
style P fill:#fab387,color:#11111b
style HIT fill:#a6e3a1,color:#11111b

Cuándo tiene sentido (y cuándo no)

Un contenedor está justificado cuando se cumplen dos condiciones a la vez. La primera: el trabajo choca de verdad contra una de las fronteras del isolate —lenguaje, binario, recursos o sistema de ficheros—. La segunda: ese trabajo es una porción acotada que puedes poner detrás de un límite de petición limpio, de modo que el Worker le entregue una entrada y reciba una salida.

El antipatrón es el espejo de esto: enrutar toda la aplicación a través del contenedor “porque es más simple”. Al hacerlo tiras a la basura la capa global y gratuita, sumas la penalización de despertar a cada petición y reconstruyes exactamente el servidor siempre encendido del que venías huyendo, ahora con el Worker degradado a proxy tonto. La forma sana invierte los papeles: front listo y omnipresente, músculo potente pero escaso que se invoca solo por lo que nadie más puede hacer.