Contenido del curso

Primeros pasos en edge

API edge con Workers

Persistencia y archivos

Tiempo real y asíncrono

Crea tu primer Cloudflare Worker desde cero

Resumen

Configurar y desplegar aplicaciones en la red global de Cloudflare es más accesible de lo que parece. Con una cuenta gratuita, sin necesidad de tarjeta de crédito, puedes tener tu primer worker funcionando en minutos. A continuación se explican los pasos fundamentales para crear una cuenta, familiarizarte con la interfaz y construir tu primera aplicación tanto desde el dashboard como desde la línea de comandos.

¿Cómo crear una cuenta en Cloudflare y explorar la interfaz?

El proceso de registro es directo: te autentificas con el método que prefieras (por ejemplo, Gmail), respondes algunas preguntas de onboarding —como si el uso será personal o profesional— y listo, sin ingresar datos de tarjeta de crédito [0:20]. Una vez dentro, el panel principal ofrece múltiples opciones organizadas por categorías.

Dentro de la sección de cómputo, encontrarás Workers y Pages [1:00]. Aunque originalmente Cloudflare lanzó Pages para simplificar el despliegue de aplicaciones front-end, con el tiempo descubrieron que esta separación generaba complejidad adicional. Actualmente, las nuevas funcionalidades se lanzan exclusivamente en Workers, convirtiendo a Pages en un servicio en proceso de descontinuación. Por eso, todo el desarrollo —ya sea back-end, front-end u otros servicios— se realiza directamente en Workers.

¿Qué opciones ofrece un worker después de crearlo?

Al crear tu primer worker con un template de "Hello World" [1:52], Cloudflare aprovisiona los recursos en segundos. El código inicial es muy sencillo: un console.info y un Response que devuelve el saludo. Una vez desplegado, la interfaz presenta varias pestañas importantes:

Métricas: analítica de uso del worker.
Deployments: historial de despliegues, que luego puedes conectar con un repositorio de GitHub.
Bindings: permite conectar bases de datos, KVs y otros servicios de Cloudflare [2:40].
Observabilidad: integrada por defecto con el dashboard.
Settings: configuraciones avanzadas como dominio por defecto, custom domain, preview URLs para multi staging donde cada pull request vive en una URL independiente, variables, secrets y configuraciones de runtime [3:05].

El editor en línea funciona bien para workers simples, pero cuando trabajas con frameworks o TypeScript, el código aparece minificado u ofuscado, lo que hace impráctica la edición desde el navegador [3:50].

¿Cómo funciona el despliegue global de Cloudflare?

Cada vez que guardas y despliegas cambios, Cloudflare distribuye tu aplicación a través de todos sus datacenters a nivel global, haciendo que los despliegues sean extremadamente rápidos [4:35]. Esto se comprobó al modificar el "Hello World" para incluir saludos en inglés y español, verificando el resultado casi de inmediato en la URL asignada.

¿Cómo crear un worker desde el CLI y conectarlo con GitHub?

Para un flujo de trabajo profesional, la creación desde la línea de comandos es el camino recomendado. El primer paso es seleccionar la versión de Node.js —en este caso la versión 22— [5:10]. Un dato relevante: aunque Workers soporta JavaScript, TypeScript, Python y Rust (todo lo que compile a WebAssembly), la documentación está mayoritariamente orientada a JavaScript y TypeScript.

El CLI genera toda la estructura del proyecto mediante scaffolding, instala dependencias y permite conectar el repositorio con GitHub y la cuenta de Cloudflare para aprovechar las ventajas de CI/CD [5:40].

¿Qué archivos de configuración son esenciales?

Siguiendo la documentación oficial, se deben configurar varios archivos clave:

Plugin de Vite para workers: se agrega para que el proyecto se ejecute correctamente en la red de Cloudflare, útil también al migrar aplicaciones existentes [6:30].
vite.config.ts: se actualiza con las líneas indicadas en la documentación, ubicado en la raíz del proyecto.
Archivo wrangler (grungler): es el archivo más importante de un worker [7:05]. Define el nombre, el compatibilityDate, los assets, los bindings y demás configuraciones avanzadas.
tsconfig-worker.json: configuración específica de TypeScript para el worker.
worker/index.ts: archivo principal que contiene la lógica del worker desplegado.

La propiedad main dentro del archivo de configuración hace referencia directa al worker que se va a desplegar. Cuando la aplicación combina front-end y back-end en el mismo worker, se configura una especie de routing: las rutas definidas se atienden por el worker, y cuando no existen, se sirve la SPA configurada con Vite [8:10].

La documentación oficial de Cloudflare es el recurso principal para resolver dudas y seguir cada paso de configuración. Comparte en los comentarios cómo fue tu experiencia creando tu primer worker.

Santiago Pineda Botero

student•

1. Diagnóstico breve de la clase

Qué promete: Crear un Cloudflare Worker desde cero, integrando front-end (Vite) y back-end en un solo despliegue.
Qué entrega realmente: Un tutorial guiado de "copiar y pegar" basado en la documentación oficial, con navegación superficial por el dashboard.
Para quién sirve: Usuarios sin experiencia técnica previa que necesitan una guía visual para el proceso de onboarding y despliegue inicial.
Principal límite: Ausencia de explicación sobre el modelo de ejecución (Isolate) y la arquitectura de red, priorizando el uso de herramientas sobre el entendimiento del sistema.

2. Qué enseña realmente y qué solo aparenta enseñar

Enseña: Navegación por el dashboard, uso básico de wrangler CLI, estructura de archivos de un proyecto (Vite + Worker) y despliegue.
Aparenta enseñar: Arquitectura serverless y desarrollo profesional. El instructor utiliza terminología avanzada (bindings, routing, SPA) sin explicar los fundamentos técnicos que los sustentan.

3. Contenidos de la clase

Explícitos: Creación de cuenta, uso de plantillas, configuración de wrangler.toml, integración con GitHub, edición en línea y despliegue mediante CLI.
Inferenciales: La existencia de una capa de enrutamiento (routing) que separa peticiones de back-end de las rutas de front-end (SPA).
Ausentes: Ciclo de vida de una petición HTTP en la red de Cloudflare, gestión de errores, límites de ejecución (CPU/memoria), estrategias de depuración y el propósito técnico del compatibilityDate.

4. Vacíos, omisiones y riesgos pedagógicos

Falla pedagógica: Se presenta el archivo wrangler.toml como el "más importante" sin explicar la jerarquía de configuración ni el conflicto potencial con el dashboard.
Riesgo: Se fomenta la edición en línea en el dashboard, una mala práctica que el propio instructor admite genera código "ofuscado" difícil de mantener.

5. Evaluación por nivel

Qué sí corresponde: Configuración de entorno y despliegue de un "Hello World".
Qué faltó y sí era exigible: Explicación del compatibilityDate y su impacto en la estabilidad del código ante actualizaciones de la plataforma.
Qué no sería razonable exigir: Implementación de arquitecturas complejas de microservicios o gestión avanzada de bases de datos D1.

6. Evidencia

Evidencia directa: Transcripción donde el instructor afirma que "Workers y Pages es básicamente lo mismo" y que Pages está siendo "descontinuado".
Inferencias: La clase depende totalmente de la documentación externa, funcionando como un espejo de los Get Started oficiales.
Límites del material: El código TypeScript se trata como un bloque estático sin análisis de sintaxis o lógica.

7. Conclusión honesta

Principal fortaleza: Accesibilidad para principiantes.
Principal debilidad: Falta de rigor técnico; el estudiante aprende a ejecutar comandos pero no a entender la plataforma.
Mejora mínima indispensable: Explicar el flujo de una petición a través de la red de Cloudflare y el propósito real de la configuración de runtime.

8. 5 preguntas avanzadas

Pregunta: ¿Por qué el instructor afirma que Cloudflare está "descontinuando" Pages en favor de Workers? Respuesta: Es una interpretación errónea del instructor; ambos servicios coexisten bajo la misma infraestructura, pero con enfoques de despliegue distintos. Elemento concreto: Afirmación del instructor sobre la descontinuación de Pages. Por qué importa: Genera confusión sobre el ecosistema de productos de Cloudflare. Qué revela sobre el rigor real: Baja precisión técnica y confusión conceptual. Aporte para la comunidad: Clarificar que Pages y Workers son complementarios.

Pregunta: ¿Qué impacto tiene el compatibilityDate en el comportamiento del worker? Respuesta: Define la versión de la API y las funcionalidades del runtime que el worker puede utilizar, garantizando la compatibilidad con versiones futuras. Elemento concreto: Mención del compatibilityDate en el archivo wrangler.toml. Por qué importa: Es el mecanismo de versionado de la plataforma. Qué revela sobre el rigor real: Omisión crítica; se menciona sin explicar su función de seguridad. Aporte para la comunidad: Prevenir errores de despliegue por cambios de API.

Pregunta: ¿Qué sucede si el archivo wrangler.toml y el dashboard tienen configuraciones contradictorias? Respuesta: El despliegue a través de CLI (wrangler) suele sobrescribir o ignorar configuraciones manuales del dashboard. Elemento concreto: La dualidad entre configuración por dashboard y por archivo wrangler.toml. Por qué importa: Es la causa principal de comportamientos inesperados en producción. Qué revela sobre el rigor real: La clase ignora la jerarquía de configuración. Aporte para la comunidad: Establecer el CLI como única fuente de verdad.

Pregunta: ¿Por qué la edición en línea en el dashboard es desaconsejada para proyectos complejos? Respuesta: Porque el código se despliega sin un proceso de build, minificación o validación de tipos, impidiendo la detección de errores. Elemento concreto: Advertencia del instructor sobre el código "minificado u ofuscado". Por qué importa: El dashboard no es un entorno de desarrollo profesional. Qué revela sobre el rigor real: El instructor reconoce la limitación pero no enseña el flujo de CI/CD correcto. Aporte para la comunidad: Fomentar el desarrollo local.

Pregunta: ¿Qué rol cumple el archivo tsconfig-worker.json en el proyecto? Respuesta: Configura las reglas de compilación de TypeScript específicas para el entorno de ejecución de Workers, asegurando que los tipos globales estén disponibles. Elemento concreto: Creación del archivo tsconfig-worker.json. Por qué importa: Sin esto, el compilador no reconoce las APIs de Cloudflare. Qué revela sobre el rigor real: Se trata como un paso mecánico sin explicar la configuración del compilador. Aporte para la comunidad: Entender la configuración del entorno de desarrollo.

Primeros pasos en edge

APIs sin regiones con Cloudflare Workers