[Spanish] Un sitio de 1000 páginas sin servidor ni base de datos: Astro + Claude Code

Hace unos meses empecé a ordenar los resultados de gateball en el Perú. Los datos estaban repartidos en más de diez años de entradas del blog Kantokeando: torneos, equipos, jugadores y puestos. Los fui pasando a un Excel a mano y me pregunté si se podía convertir en algo útil para la comunidad, que busca saber quién ganó, cuántos títulos tiene un equipo o cómo le fue a un jugador.

Así nació Gate-Datos: un archivo de consulta con 189 torneos, 203 equipos, 538 jugadores y más de mil resultados, de 2014 a 2026. Es solo de lectura, sin login, sin formularios y sin base de datos en el camino.

La portada: un buscador y el último torneo. Todo es HTML generado de antemano.

La idea: generar todo antes, servir solo archivos

Los datos cambian poco. Se agregan unos 4 a 8 registros cada dos semanas, así que no hace falta consultar nada en tiempo real. Eso me llevó a esta arquitectura:

1. El Excel es la única fuente de verdad.
2. Un pipeline en Python (pandas, rapidfuzz) lo valida, normaliza los nombres y exporta JSON.
3. Astro lee esos JSON y genera el sitio entero como HTML estático.
4. Cloudflare sirve los archivos.

No hay servidor de aplicación, API ni consultas en cada visita. Cada página ya está construida antes de que alguien la pida.

Cada torneo tiene su página con los podios por categoría. Una página más de las 996 que genera el build.

Por qué Astro

Con los datos actuales, un solo build genera 996 páginas (una por torneo, jugador, equipo, año, tabla de posiciones y más) en unos 11 a 13 segundos. El sitio completo pesa unos 51 MB. Reconstruirlo entero en cada actualización me sale gratis en la práctica, y por eso lo hago a propósito: la normalización de nombres es global, y un registro nuevo puede cambiar datos que ya existían. Un build completo siempre es coherente.

Lo que le ganamos al usuario:

• Velocidad: cada página es HTML listo, sin esperar a un servidor ni a que un framework "arme" la pantalla en el navegador.
• Poco JavaScript: Astro no envía JS que no pidas. En mi caso solo viaja un índice de búsqueda de unos 90 KB. Los JSON grandes (el de jugadores pesa unos 2 MB) los usa únicamente el build y nunca llegan al navegador.
• Hosting barato y robusto: son archivos estáticos. No hay nada que se caiga por exceso de consultas.

La arquitectura de islas, explicada simple

Una página web tradicional con framework suele cargar JavaScript para toda la pantalla, aunque la mayor parte sea texto que nunca cambia. La arquitectura de islas parte de lo contrario: la página es HTML estático (el "mar"), y solo las partes que realmente necesitan interactividad son "islas" con su propio JavaScript. Un botón de tema oscuro o un buscador pueden ser islas, y el resto de la página no paga ese costo.

Un punto de honestidad: en este proyecto casi no usé islas. No metí React ni otro framework de UI. Mi interactividad es mínima: un buscador con sugerencias y un botón de tema claro/oscuro, ambos con scripts pequeños. Con eso, casi todo el sitio es HTML puro. Astro me permitió no pensar en hidratación hasta que de verdad la necesitara, y esa es la gracia: lo estático es el punto de partida y lo interactivo se agrega solo donde hace falta.

La ficha de un equipo: casi todo es HTML estático; el buscador y el botón de tema son las únicas partes con JavaScript.

Cómo lo publico

El sitio vive en Cloudflare Workers con archivos estáticos, en el plan gratuito. Está conectado a mi repositorio de GitHub: cada git push a la rama principal dispara el build y el despliegue en uno o dos minutos. El dominio propio se asocia al mismo proyecto. Hasta ahora he gastado 8 de los 3.000 minutos de compilación gratuitos al mes, y los archivos estáticos no cuentan contra el límite de peticiones.

En el celular: el mismo sitio, sin app aparte.

También agregué sitemap y robots.txt, y envié el sitio a Google Search Console.

Cómo me ayudó Claude Code

Trabajé con Claude Code como compañero de programación durante todo el proyecto, y esto es lo que más me sirvió:

• El pipeline de datos. Los nombres en las entradas del blog vienen con variantes: tildes, orden Nombre/Apellido invertido, apodos, tipeos. Claude escribió los scripts que proponen qué nombres son la misma persona, pero la decisión siempre fue mía, y las reglas confirmadas quedaron en archivos de alias. Esa separación (la máquina propone, el humano decide) fue clave para no mezclar a dos personas distintas.
• Convertir un diseño en Astro. Partí de un diseño exportado y Claude lo reescribió en componentes de Astro con CSS propio, tokens de color claro y oscuro y sin librerías de UI.
• Un archivo de memoria del proyecto. Mantengo un CLAUDE.md con las decisiones: qué se muestra, qué no, cómo se actualiza. Cada sesión nueva parte con ese contexto y no tengo que explicar todo de nuevo.
• Revisión visual. Para cambios de diseño, Claude levanta el sitio, saca capturas en escritorio y móvil, y yo veo el resultado antes de dar el visto bueno. Por ejemplo, me di cuenta de que las tarjetas con forma de arco parecían lápidas para un público mayor, y en una sola conversación se rediseñaron en cuatro páginas y se publicaron.
• Documentación y despliegue. Los pasos de publicación, los riesgos y las decisiones quedaron escritos en el repositorio, listos para retomar meses después.

Algo que aprendí: la IA rinde mucho más cuando el proyecto tiene reglas claras escritas (la fuente de verdad, qué nunca se toca, cómo se valida). Con eso, en vez de adivinar, trabaja dentro de tus límites.

Lo que me llevo

• Para datos que cambian de vez en cuando, generar estático es más simple, más rápido y más barato que un backend.
• Astro hace natural ese enfoque: poco JavaScript, builds rápidos y una forma de crecer hacia la interactividad cuando la necesites.
• Claude Code acelera mucho, siempre que tú decidas lo que importa: los datos, las reglas y el diseño final.

Si te interesa ver el resultado, está en gatedatos.org.pe, y el código es público en GitHub.