Caprini Dev

sagas/odisea-del-blog-maestro/007-la-web-viva.md

2026-03-24 published

Episodio 007 — La web viva

Episodio 007 — La web viva

Serie: bitácora de ingeniería — caprini.dev
Slug: 007-la-web-viva
Resumen: el progress tracker (projects/001-progress-tracker/tracker.mjs) sigue siendo un backend ligero: llama a la API de GitLab y vuelca datos en consola (y el bloque para X). En este episodio añadimos un segundo destino de esos mismos hechos: un archivo src/content/last-activity.json que el sitio importa en build como si fuera un latido del repositorio visible en el Hero de la Home.

Por qué JSON estático y no una base de datos

  • El blog es estático: Astro genera HTML a partir del contenido en disco.
  • Persistir “último commit” en Postgres/SQLite añadiría hosting, migraciones y superficie de fallo sin beneficio para este caso.
  • El contrato es deliberadamente simple: un archivo versionado o regenerado tras ejecutar el tracker; la Home lee mensaje, fecha ISO y enlace al commit.

Flujo end-to-end

  1. Tracker (Node): tras obtener el último commit de main, construye un payload con título de mensaje, committedAt (ISO de GitLab), dateHuman (texto amigable con Intl.DateTimeFormat en és-AR), SHA, URL y trackerRunAt`.
  2. Escritura: writeFile hacia src/content/last-activity.json en la raíz del monorepo (ruta resuelta desde __dirname del script).
  3. Astro: src/pages/index.astro importa ese JSON y muestra una franja tipo badge: Última actividad, mensaje truncado si hace falta, y tiempo relativo (Intl.RelativeTimeFormat, és`) calculado en momento de build para que “hace X” siga teniendo sentido al publicar de nuevo.

Lecciones breves

  • Separación: la API sigue siendo la fuente en runtime del script; el JSON es la foto que el blog consume.
  • Humano vs máquina: guardamos ISO para lógica y una cadena dateHuman para lectura; el relativo en la UI evita depender solo de la última ejecución del tracker.
  • Sin DB: si el archivo no se ha generado aún, la Home muestra un mensaje de invitación a ejecutar el tracker.

Próximo paso lógico

Automatizar (CI o hook) la ejecución del tracker antes del build de producción, o documentar en SPEC-001 el orden “tracker → build → deploy” para que el latido no quede desfasado respecto a GitLab.