Bajo el capó: todo colapsa en un fetch handler

Un framework full-stack parece una máquina enorme: enrutado por archivos, renderizado de componentes, capas de datos, middleware, streaming. Pero Cloudflare no ejecuta ninguna de esas abstracciones directamente. Lo que el runtime invoca en producción es lo de siempre, el átomo del track: una sola función fetch que recibe una Request y devuelve una Response. Toda la maquinaria del framework se pliega, en tiempo de build, dentro de esa única puerta. Ver ese colapso con claridad es lo que separa a quien usa un framework de quien lo entiende.

Todo colapsa en fetch

Cuando ejecutas el build de un framework con adaptador de Cloudflare, ocurre una fusión. El enrutado —esa tabla que asocia URLs con páginas o con handlers— se compila en una función de despacho. El motor de renderizado se empaqueta como una dependencia más del bundle. El middleware se encadena. Y todo eso se envuelve en una única función de entrada con la firma que ya conoces de memoria:

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    // aqui vive, comprimido, TODO el framework:
    // 1. casa la URL con una ruta
    // 2. ejecuta loaders o carga de datos
    // 3. renderiza el componente a HTML
    // 4. devuelve la Response
    return await frameworkDispatch(request, env, ctx);
  },
};

Ese frameworkDispatch imaginario es la esencia: cualquiera que sea el framework, su servidor entero queda reducido a lógica que, dada una Request, elige qué Response fabricar. No hay una segunda naturaleza escondida. El framework es, tras el build, una función pura del edge con mucho código dentro.

Anatomía del Worker generado

El artefacto de despliegue tiene dos mitades que conviene distinguir, porque el orden en que se consultan decide el flujo de cada petición. Por un lado, el Worker: el fetch handler con toda la lógica del servidor. Por otro, los assets estáticos: los archivos ya generados —CSS, JavaScript de cliente, imágenes, páginas prerenderizadas— que no necesitan cómputo.

Ante una petición, la plataforma resuelve primero si corresponde a un asset estático; si existe, lo sirve directamente desde el edge sin despertar tu lógica. Si no, invoca el fetch handler, que enruta, carga datos y renderiza. Esa preferencia por el asset es lo que hace que servir lo estático sea prácticamente gratis y que el cómputo se reserve para lo dinámico.

flowchart TB
Req[Request entra] --> Q{es un asset estatico}
Q -->|si| AS[sirve el archivo desde el edge]
Q -->|no| FH[invoca el fetch handler]
FH --> RT[casa la ruta]
RT --> LD[carga datos con loaders]
LD --> RN[renderiza a HTML]
RN --> Res[Response sale]
style FH fill:#fab387,color:#11111b
style AS fill:#a6e3a1,color:#11111b

El manifiesto wrangler.jsonc refleja exactamente esas dos mitades: un main que apunta al Worker generado y un bloque assets que apunta al directorio de estáticos. Es la misma estructura de cualquier Worker con assets; el framework solo la rellena por ti:

{
  "name": "mi-app",
  "main": ".output/worker.js",
  "compatibility_date": "2026-01-01",
  "assets": { "directory": ".output/public" }
}

No hay servidor que mantener

Aquí es donde el modelo del edge se separa con nitidez del despliegue tradicional. Un framework en un servidor de Node arranca un proceso que abre un puerto, se queda a la escucha con un listen y atiende peticiones en un bucle que vive indefinidamente. Ese proceso guarda estado en memoria entre peticiones y consume recursos aunque nadie llame.

En Workers no hay nada de eso. No arrancas un proceso ni escuchas en un puerto: exportas una función y el runtime la invoca, una vez por petición, sobre un isolate que despierta en una fracción de milisegundo y se aparta cuando termina. El adaptador es precisamente quien traduce el modelo “servidor de larga vida” del framework al modelo “función efímera por petición” del edge.

Esa diferencia no es un detalle de despliegue, sino un cambio en cómo escribes el código del servidor. Todo lo que un framework de Node daba por sentado —una conexión a base de datos abierta al arrancar y reutilizada durante horas, un caché en memoria que crece con el tiempo, un temporizador de fondo— deja de tener sentido cuando la unidad de ejecución vive lo que dura una petición. El adaptador salva la mayoría de esas distancias por ti, pero la responsabilidad de no escribir contra un modelo que ya no existe sigue siendo tuya.

El átomo como herramienta de depuración

Saber que todo colapsa en un fetch handler no es trivia arquitectónica: es una herramienta práctica que usarás a diario. Cuando una petición se comporta raro, el modelo te da un lugar concreto donde pensar. El framework, por muchas capas que tenga, recibió una Request y devolvió una Response; el fallo está en esa transformación, y puedes razonarla como razonarías cualquier Worker.

Esa localización mental se traduce en gestos concretos, porque el punto de entrada es único y conocido. Ninguno de ellos exige entender las tripas del renderizador: bastan porque sabes exactamente dónde entra y sale cada petición.

• Envolver el fetch handler generado con el tuyo para inspeccionar la Request antes de que el framework la despache.
• Añadir cabeceras de diagnóstico a la Response de salida sin tocar el interior del framework.
• Conectar wrangler tail y leer, en esa misma función, todo lo que el framework registra en producción.
• Medir el tiempo dentro del handler para ubicar en qué capa —ruta, datos, render— se va la latencia.