Cómo se resuelve cada petición

Cada petición que llega a Cloudflare recorre un árbol de decisión fijo antes de que se ejecute una sola línea de tu Worker. Saber ese orden —quién resuelve el DNS, qué gana entre un custom domain y una route, cuándo se sirve un asset en lugar de tu código— transforma el enrutado de una fuente de sorpresas en un cálculo predecible. Esta lección junta las piezas de las anteriores en una sola línea de tiempo.

Del DNS al edge

Antes de hablar de Workers, la petición tiene que llegar. El navegador resuelve el hostname; si su registro es proxied, el DNS de Cloudflare devuelve una IP anycast y la petición aterriza en el centro de datos más cercano. Solo entonces empieza el pipeline del edge: TLS, seguridad, caché y, en su momento, el enrutado a Workers.

Si el registro es DNS-only, nada de esto ocurre: el tráfico va directo al origen y tu Worker es invisible. El enrutado, por tanto, no empieza en tu configuración de Workers, sino en el DNS; es la premisa que desarrolla la última lección de este nivel.

flowchart TD
A[Peticion llega al edge] --> B{Casa un custom domain o una route}
B -->|No| C[Sale del enrutado de Workers y sigue al origen]
B -->|Si| D[Se elige el patron mas especifico]
D --> E{El Worker tiene assets}
E -->|No| F[Corre tu Worker]
E -->|Si| G{run_worker_first}
G -->|Si| F
G -->|No| H{Existe el asset pedido}
H -->|Si| I[Se sirve el asset sin ejecutar codigo]
H -->|No| F

Léelo de arriba abajo: cada rombo es una pregunta con respuesta binaria y solo hay una salida por camino. Ese determinismo es la propiedad más valiosa del sistema: dada una URL y tu configuración, el Worker o el asset que responde está decidido de antemano.

El orden de decisión

Dentro del enrutado de Workers, la coincidencia manda. Un custom domain casa por hostname exacto; una route, por patrón, y entre routes gana la más específica. Si nada casa, la petición abandona el enrutado de Workers y sigue su camino normal, hacia la caché o el origen. Una petición ejecuta un solo Worker: no hay encadenamiento implícito entre patrones que se solapan.

El árbol completo se puede resumir en tres preguntas encadenadas, siempre en el mismo orden:

Assets o Worker: quién responde primero

Cuando tu Worker lleva assets estáticos, entra la tercera decisión. El comportamiento por defecto es assets primero: si la URL casa con un fichero del directorio de assets, se sirve sin ejecutar tu código. Si no casa ningún asset y hay script, corre el Worker. Y el Worker siempre puede devolver la pelota a los assets con env.ASSETS.fetch(request):

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    if (url.pathname.startsWith("/api/")) {
      return new Response("respuesta dinamica");
    }
    // Delega el resto a los ficheros estaticos
    return env.ASSETS.fetch(request);
  },
};

Dos ajustes cambian el guion por defecto:

{
  "assets": {
    "directory": "./dist",
    // Corre el Worker antes que los assets, con excepciones
    "run_worker_first": ["/api/*", "!/api/docs/*"],
    // Que hacer cuando no casa ningun asset
    "not_found_handling": "single-page-application"
  }
}

Con run_worker_first inviertes el orden para ciertos patrones —útil para autenticar o registrar antes de servir—; con not_found_handling decides si un fallo de asset devuelve el index.html de una SPA, una página 404 o nada. Quien migra de Pages a Workers tropieza aquí: Pages ejecutaba la función antes que el asset, y Workers hace lo contrario salvo que lo pidas.