Episodio 027 — Conectando con el mundo exterior
Durante varias iteraciones trabajamos en modo estático disciplinado: escribimos Markdown, compilamos Astro y publicamos HTML listo para servir. Esa base sigue siendo correcta, pero ahora necesitábamos algo distinto en /proyectos: que las tarjetas respiraran con datos reales del repositorio, no solo con texto congelado en el último build.
Lo estático (build-time) y por qué sigue importando
En build-time ganamos estabilidad:
- estructura de rutas determinista,
- contenido versionado,
- rendimiento alto al servir archivos precompilados.
En este modelo, el HTML nace con información conocida al momento de compilar. Si un repositorio gana una estrella después, el número no cambia hasta el siguiente deploy.
Lo dinámico (run-time) y el nuevo latido
Para mostrar señales vivas, movimos una parte al navegador:
- un componente
GitLabStats.astroque ejecutafetchen cliente, - consulta la API pública de GitLab,
- actualiza estrellas, forks y lenguaje principal cuando llega la respuesta.
El resultado es una mezcla útil: la página sigue siendo estática en su esqueleto, pero incorpora un punto de telemetría real en tiempo de ejecución.
Seguridad primero: datos públicos, cero tokens
El límite era claro desde el inicio: nada de credenciales en frontend.
Por eso el monitor consume endpoints públicos y maneja degradación visual:
- punto verde si la API responde,
- punto rojo si falla.
Sin claves embebidas, sin Authorization, sin riesgo de filtrar secretos por inspección del cliente.
Cierre
La lección no es “todo dinámico” ni “todo estático”. Es elegir el sitio correcto para cada cosa: build-time para la arquitectura del contenido, run-time para el pulso cambiante del mundo exterior. En /proyectos, ese pulso ahora se ve.