Un JSON en Google Drive en lugar de un CMS: elegir la herramienta aburrida
Un club náutico edita sus noticias en un fichero de Google Drive. Un AMPA tiene una landing sin backend. No es dejadez: es haber definido el alcance por lo que el proyecto no iba a hacer.
ArquitecturaAstroNext.jsRendimientoAccesibilidad
Dos de los sitios que más contento me tienen son los que menos tecnología llevan.
Uno es el blog de un club náutico. Otro es la landing de un AMPA. Ninguno tiene base de datos. Uno de ellos no tiene ni backend. Y en los dos casos fue una decisión, no una limitación.
El club náutico: el CMS es un fichero
El club quería publicar noticias y actividades. Lo que no quería era pagar un hosting con base de datos ni aprender a usar un panel de administración.
La solución fue quitar el backend de la ecuación: la aplicación lee un JSON alojado en Google Drive. Una variable de entorno, GOOGLE_DRIVE_URL, y la web renderiza a partir de ahí en servidor.
Lo que desaparece de golpe con esa decisión:
No hay base de datos que mantener, ni migraciones, ni copias de seguridad.
No hay panel de administración que construir, ni sesiones, ni recuperación de contraseña.
No hay credenciales que rotar.
La factura mensual de infraestructura es cero.
Y el club edita el contenido en una herramienta que ya sabe usar, sin que nadie le enseñe nada.
Ese último punto es el que casi siempre se subestima. La parte difícil de un CMS para un cliente pequeño no es construirlo: es que alguien lo use seis meses después sin llamarte.
Hay un detalle que me gusta especialmente. Las noticias llegan a menudo sin foto —eso es lo normal, no la excepción— así que cuando falta la imagen se resuelve una coherente con el tema desde la API de Unsplash. El sitio nunca se ve a medio hacer. Es una línea de defensa contra la realidad de que quien publica tiene prisa.
Y los filtros y el buscador van en cliente, porque con el conjunto completo de noticias ya cargado no hay motivo para volver al servidor. Es instantáneo y es menos código.
El compromiso, dicho claro: no hay editor visual y el sitio depende de que el JSON esté bien formado. Si alguien se come una coma, se rompe. A cambio, el coste de operación es cero y no hay nada que se pueda quedar sin actualizar de seguridad. Para el volumen de noticias de un club náutico, montar un CMS habría sido desproporcionado.
El AMPA: el alcance definido por lo que no se hace
El caso del AMPA es más radical, porque el trabajo interesante fue de recorte.
El AMPA ya tenía contratada una plataforma de gestión donde se pagan las cuotas y se apuntan los niños a las actividades. Lo que no tenía era una puerta de entrada presentable.
Así que el alcance se definió al revés, por la negativa: sin backend, sin login, sin formularios y sin base de datos. Una sola página, tres páginas legales de verdad y un 404. Todas las llamadas a la acción llevan a la plataforma que ya existe.
Ahí, elegir Astro con salida estática en lugar de Next fue lo evidente. Sin interactividad que justifique hidratación, un generador que manda cero JavaScript por defecto es la herramienta adecuada. Yo trabajo con Next todos los días y no era el sitio para usarlo.
El resultado: Lighthouse 100 en las cuatro categorías y cero incidencias de axe-core en WCAG 2.1 AA. Y esto último no es un adorno en la web de un centro educativo público.
Dos decisiones de las que me acuerdo:
Fuentes autohospedadas vía @fontsource: Fraunces variable para títulos, Atkinson Hyperlegible para el texto. Ni una petición a Google Fonts, lo que ayuda al rendimiento y a la privacidad a la vez. Atkinson Hyperlegible, además, está diseñada específicamente para mejorar la legibilidad.
SEO técnico completo aunque sea una sola página: sitemap, JSON-LD, metadatos OG y Twitter. Cuesta una tarde y es lo que hace que el sitio aparezca cuando un padre lo busca.
El contraste: cuando sí hace falta todo
No es que la respuesta sea siempre "menos". Otro de mis proyectos, un SaaS de tasaciones judiciales, lleva Drizzle ORM con migraciones versionadas, la API de OpenAI, Stripe, un Chromium recortado corriendo dentro de una función para generar PDFs, extracción de texto de PDFs, correo transaccional y un panel de super-admin. Es el proyecto con más recorrido que tengo, unos noventa commits.
¿Es sobreingeniería? No. Ahí cada pieza responde a un requisito que no se puede quitar: hay dinero de suscripciones, hay documentos legales que hay que emitir, hay datos de despachos distintos que no se pueden mezclar y hay un cálculo que si sale mal acaba en un escrito judicial.
La diferencia entre los dos casos no es el gusto por la tecnología. Es que el requisito manda. Y por eso mismo el proyecto grande tiene tests con Vitest en la lógica de cálculo y el pequeño no: en uno el error se paga y en el otro se arregla en dos minutos.
Las preguntas que me hago ahora
Antes de meter una pieza de infraestructura en un proyecto pequeño:
¿Quién va a mantener esto en un año? Si la respuesta no es "yo, cobrando por ello", cada pieza que añades es una que se quedará sin actualizar.
¿Quién va a usar el panel? Si es una persona que no trabaja con ordenadores todo el día, un fichero en una herramienta que ya conoce le gana a la interfaz más bonita que le puedas construir.
¿Qué pasa si esto se rompe un domingo? Un sitio estático no se rompe. Uno con base de datos, sí.
¿Puedo definir el alcance por lo que no voy a hacer? Esta es la que más me ha servido. En el AMPA, escribir "sin backend, sin login, sin formularios, sin base de datos" en la primera línea del README hizo que todas las decisiones siguientes fueran fáciles.
La herramienta aburrida casi nunca es la que más te apetece usar. Suele ser la correcta.
