Hola mundo: escribir, correr con wrangler dev y ver la respuesta

Ha llegado el momento de cerrar el círculo: escribir un Worker de verdad, arrancarlo en tu máquina con wrangler dev y ver su respuesta en el navegador. Más allá del “hola mundo”, lo que vas a interiorizar es el ciclo de desarrollo local —editar, guardar, recargar— y por qué lo que corre en tu portátil es exactamente el mismo runtime que correrá en producción.

El Worker mínimo

Un proyecto de Worker necesita dos cosas: el código y un archivo de configuración. Puedes crearlos a mano o dejar que la CLI te ande el andamiaje:

npm create cloudflare@latest mi-primer-worker

Pero conviene ver las piezas desnudas al menos una vez. El código va en src/index.ts:

export default {
  async fetch(request, env, ctx) {
    return new Response("Hola mundo desde el edge");
  },
};

Y la configuración, en wrangler.jsonc, que le dice a Wrangler cómo se llama tu Worker y dónde está su punto de entrada:

{
  "name": "mi-primer-worker",
  "main": "src/index.ts",
  "compatibility_date": "2026-01-01"
}

Con esos dos archivos ya tienes un Worker completo. No hace falta framework, ni servidor, ni configuración de red. El compatibility_date fija qué versión del comportamiento del runtime usas: un mecanismo que garantiza que tu Worker no cambie de conducta cuando la plataforma evoluciona.

Si usaste npm create cloudflare, verás también un package.json con Wrangler como dependencia, un tsconfig.json con los tipos del runtime y un .gitignore. Nada de eso es esencial para que el Worker corra —el código y wrangler.jsonc bastan—, pero es el andamiaje cómodo con el que trabajarás a diario.

wrangler dev

Wrangler es la CLI oficial de la plataforma. El comando que usarás mil veces es wrangler dev:

npx wrangler dev

Al ejecutarlo, Wrangler levanta un servidor local —normalmente en http://localhost:8787— que ejecuta tu Worker. Abres esa URL en el navegador y ves tu “Hola mundo”. Acabas de completar el ciclo entero: petición del navegador, tu fetch handler se ejecuta, devuelve una Response, y la ves renderizada.

Para el modo local no necesitas ni cuenta ni login: todo corre en tu máquina. Eso significa que puedes empezar a escribir Workers sin dar de alta nada, y solo pisas la nube cuando decides desplegar.

Por defecto wrangler dev corre en local, con los bindings emulados en tu máquina. Si necesitas hablar con recursos reales de tu cuenta —un KV de producción, por ejemplo—, el flag --remote ejecuta el Worker en la red de Cloudflare contra esos recursos. Para aprender y para el bucle rápido, el modo local es lo que quieres.

El ciclo: editar, guardar, recargar

Aquí está la parte adictiva. Con wrangler dev corriendo, cambia el texto de la Response:

return new Response("Hola de nuevo, ahora con hot reload");

En cuanto guardas el archivo, Wrangler detecta el cambio y recarga el Worker al instante. Refrescas el navegador y ves el texto nuevo, sin reiniciar nada a mano. Ese bucle —editar, guardar, refrescar— dura milisegundos, y es el corazón del desarrollo en Workers.

flowchart LR
Editar --> Guardar
Guardar --> Recargar[Wrangler recarga]
Recargar --> Ver[Ver en el navegador]
Ver --> Editar

La brevedad de ese ciclo no es un lujo: cambia cómo programas. Cuando probar una idea cuesta segundos, exploras más, arriesgas más y aprendes más rápido. El desarrollo en Workers premia la iteración corta, y wrangler dev es el motor que la hace posible.

Un apunte para no perder el hilo: mientras iteras, el estado en memoria de tu Worker se reinicia con cada recarga, igual que se reiniciará en producción entre peticiones. El ciclo local no solo te enseña tu código; te acostumbra, desde el primer minuto, a que un Worker no guarda nada entre ejecuciones. Esa lección la formalizaremos en la última lección del nivel.

Descompuesto, el ciclo son cuatro pasos que repetirás sin pensar:

• Editas el código en tu editor.
• Guardas, y Wrangler detecta el cambio.
• Recarga el Worker sobre workerd, en milisegundos.
• Refrescas el navegador y ves el resultado.

Y si el puerto por defecto está ocupado, se lo cambias sin ceremonia:

npx wrangler dev --port 3000

Qué corre por debajo

Aquí está la idea que separa a Workers de casi cualquier otra plataforma. Cuando ejecutas wrangler dev, no corre un emulador ni una imitación de la nube. Corre workerd: el mismo runtime, de código abierto, que Cloudflare ejecuta en producción en su red global. En local lo orquesta Miniflare, pero el motor que ejecuta tu código es el de verdad.

# Cuando estas listo, el mismo codigo va a produccion:
npx wrangler deploy

Un solo comando, wrangler deploy, empaqueta tu Worker y lo publica en la red global. En segundos, tu función pasa de localhost:8787 a ejecutarse en cientos de ubicaciones. No hay servidores que aprovisionar ni regiones que elegir: el mismo código que probaste en local es el que atiende al mundo.

Cuando el Worker ya está en producción y quieres ver qué hace bajo tráfico real, wrangler tail transmite sus logs en vivo desde la red global. El ciclo local resuelve casi todo el trabajo; tail cubre lo que solo aparece con usuarios de verdad.