La plataforma developer de Cloudflare: Workers (isolates), D1, R2, KV, Durable Objects, Queues, Workers AI, Vectorize, Hyperdrive, Pages y Wrangler.
Cada nivel construye sobre el anterior. Sin saltos, sin huecos.
La visión aérea de la plataforma developer de Cloudflare: Workers en el edge, el almacenamiento (KV, R2, D1, DO), la IA, y el despliegue. El mapa mental completo.
Qué es Cloudflare y el edge: cientos de ubicaciones cerca del usuario; por qué ejecutar código ahí cambia la latencia y la arquitectura.
El modelo de ejecución de Workers: V8 isolates en vez de contenedores o funciones lambda; arranque en 0ms, sin cold starts, y sus implicaciones.
Anatomía de un Worker: el `fetch` handler que recibe una `Request` y devuelve una `Response`; el modelo mental de "una función en el edge".
Wrangler: crear un proyecto, `wrangler dev` (local con workerd), `wrangler deploy`, y `wrangler.jsonc` como el manifiesto del Worker.
El runtime de Workers: `workerd` (open source), las Web APIs estándar en vez de Node, las compatibility dates y flags, y el nodejs_compat.
Los bindings: cómo un Worker accede a recursos (KV, R2, D1, otro Worker) por el objeto `env`; capacidades declaradas, no credenciales.
Enrutar peticiones a un Worker: rutas, dominios personalizados, `workers.dev`, y cómo Cloudflare decide qué Worker atiende cada request.
Configuración: `vars` en el manifiesto, secretos con `wrangler secret`, el Secrets Store, y separar entornos sin filtrar credenciales.
Ver qué hace tu Worker: `wrangler tail`, Workers Logs, Analytics Engine para métricas propias, y depurar en producción.
Trabajar con `Request`/`Response`: leer body, cabeceras, `fetch` saliente (subrequests), y hacer streaming de respuestas con `ReadableStream`.
Servir sitios estáticos y SSR desde un Worker: la config de `assets`; en 2026 Workers tiene paridad total con Pages (assets, SSR, dominios).
Ejecutar un Worker en un horario: el `scheduled` handler y los cron triggers; tareas periódicas sin un servidor que las lance.
Componer Workers: llamar a otro Worker por RPC con service bindings (sin salir a la red); arquitecturas de microservicios en el edge.
Construir apps reales: Hono como router ligero, y frameworks full-stack (Astro, Remix, SvelteKit) desplegados en Workers.
El rendimiento del edge: Smart Placement (mover el Worker cerca de los datos), y los límites reales (tiempo de CPU, memoria, subrequests).
Más allá de Workers: Containers (ejecutar imágenes junto al edge) y Workflows (procesos durables de varios pasos con reintentos).
Workers KV: almacén clave-valor de lectura rápida y global; consistencia eventual, cache en el edge, y sus casos ideales y límites.
R2: almacenamiento de objetos compatible con S3 y SIN cargos de egress; servir archivos, backups, y el patrón de subidas presignadas.
D1 (GA): una base de datos SQLite serverless; crear la base, el binding, y ejecutar SQL desde el Worker con la API `prepare`/`bind`.
D1 en serio: migraciones versionadas, la Sessions API para consistencia read-your-writes, read replication global, y batch.
Durable Objects: un objeto único y direccionable con estado consistente; el actor con identidad global que resuelve la coordinación en el edge.
El estado de un DO: el storage transaccional (KV y SQLite), las alarms para despertarse solo, y la garantía de single-threaded.
DO para tiempo real: coordinar WebSockets (chat, colaboración, juegos), y la WebSocket Hibernation que reduce el coste cuando no hay tráfico.
Cloudflare Queues: productores y consumidores, entrega garantizada, batching, reintentos y dead-letter; desacoplar trabajo sin cargos de egress.
Hyperdrive: conectar tu Postgres/MySQL existente desde el edge con pooling y cache de queries; cuándo elegirlo frente a D1.
La Cache API y el tiered cache: cachear respuestas en el edge de forma programática; claves de cache, TTL, y purgado.
El árbol de decisión del almacenamiento: KV (lecturas), R2 (objetos), D1 (SQL read-heavy), DO (estado coordinado), Hyperdrive (DB existente).
Workers AI: ejecutar modelos (LLMs, embeddings, visión) sobre GPUs serverless con un binding; el catálogo de modelos y el patrón de inferencia.
Vectorize: una base de datos de vectores para búsqueda semántica; crear índices, insertar embeddings, y consultar por similitud.
AI Gateway: un proxy para tus llamadas a LLMs (propios o de terceros) con cache, rate limiting, reintentos, logs y analítica de coste.
Montar Retrieval-Augmented Generation end-to-end: embeddings con Workers AI, búsqueda en Vectorize, contexto en D1/R2, y respuesta con un LLM.
El Agents SDK sobre Durable Objects y Workflows: agentes de IA con estado persistente, herramientas, y procesos de varios pasos resilientes.
Cloudflare Pages: qué es, cómo funcionaba (frontend + Functions), y por qué en 2026 está en modo mantenimiento con todo lo nuevo yendo a Workers.
La convergencia de 2026: Workers alcanza paridad con Pages; migrar un proyecto de Pages a Workers, y por qué empezar directamente en Workers.
Seguridad de plataforma: Cloudflare Access (autenticar antes de llegar a la app), Zero Trust, y WAF/rate limiting delante del Worker.
Cloudflare Images (transformar y servir imágenes) y Stream (vídeo bajo demanda y en directo); descargar el peso de los medios al edge.
Piezas útiles: Email Workers (procesar correo entrante), Turnstile (CAPTCHA sin fricción), y el Rate Limiting nativo.
Wrangler a fondo: múltiples entornos, previews por rama, `wrangler.jsonc` a escala, y desplegar desde CI (GitHub Actions, Workers Builds).
Ensamblar una app completa: Worker + assets + D1 + DO + Queues + Workers AI; el mapa de una arquitectura full-stack sobre Cloudflare.
Pensar como el edge: minimizar subrequests y CPU, cachear con criterio, entender el modelo de precios, y cuándo el edge NO es la respuesta.
La imagen total: cómo encajan compute, storage e IA en el edge; arquitecturas de referencia, trade-offs profundos, y hacia dónde va la plataforma.
Empieza por los fundamentos y sube nivel a nivel hasta el dominio total.
Comenzar el camino →