Arquitectura Mínimamente Viable

En desarrollo de software, todo tiene un coste — así que deberíamos evitar añadir cualquier cosa que no aporte valor.

Uno de los errores más comunes es la sobreingeniería.

Pongamos como ejemplo una landing page sencilla, 100 % estática y sin interacciones de usuario complejas — algo que podría construirse con unos pocos archivos HTML y CSS estáticos y unas líneas de JavaScript. Eso sería la arquitectura mínima viable extrema (que no estoy defendiendo).

¿Deberíamos añadir más complejidad? Probablemente sí, pero analicemos cada caso según lo que cuesta y lo que aporta.

Pipeline de despliegue

Automatiza el despliegue de nuevas versiones y cambios, eliminando la necesidad de subir los archivos manualmente al servidor.

Eso implica menos errores y despliegues más rápidos — mejora la experiencia del desarrollador y reduce el tiempo de entrega.

Así que sí, claramente aporta valor.

Y su coste es mínimo: solo unas pocas líneas de código y configuración que mantener.

Añadámoslo.

Generador de sitio estático

En mi experiencia, mejora muchísimo la mantenibilidad y la experiencia de desarrollo.

Es imprescindible, porque no solo aporta valor, sino que además reduce costes.

Si alguien no está de acuerdo, que lo comente, pero sospecho que la mayoría coincidirá conmigo, así que no entraré en más detalles.

Añadámoslo.

Renderizado del lado del servidor (SSR)

Si el sitio es 100 % estático — es decir, todos los cambios provienen de acciones directas de los administradores — ¿para qué queremos SSR?

Bueno, puede que el contenido visible sea estático, pero quizá necesitemos generar algo de HTML dinámico que el usuario no ve — por ejemplo, para proteger el sitio frente a ataques CSRF.

Si necesitamos inyectar un <input hidden> con un token aleatorio en un formulario, o hacmeos SSR o algún tipo HTML rewriting al vuelo.

Pero supongamos que nuestro sitio tiene no solo contenido estático, sino HTML estático — entonces no necesitamos SSR para nada.

Si no lo necesitamos, solo aporta coste y riesgo.

Comparado con un CDN que sirva archivos estáticos, el renderizado del lado del servidor solo supone problemas: consume recursos, cuesta dinero, requiere observabilidad y monitorización, necesita mantenimiento, y puede fallar — puede caerse, sufrir ataques o simplemente tener bugs.

No lo añadamos.

Monitorización e instrumentación

Por supuesto, seguimos necesitando monitorización e instrumentación — pero solo al mismo nivel que nuestro CDN. Ni más ni menos.

Si hubiésemos elegido SSR, sería otra historia. La monitorización e instrumentación serias un peaje del SSR que evitamos al servir un sitio estático con un CDN.

No lo añadamos.

Caché

La caché siempre suena bien, pero rara vez es una buena idea.

Debería ser el último recurso en cuestiones de rendimiento, porque implica costes y riesgos reales.

En el caso de un sitio 100 % estático no importa demasiado ya que no hay inconsistencias, ni desincronización, ni riesgo de filtrar datos privados. Podríamos añadir una capa de caché sin problemas.

Pero como ya estamos desplegando en un CDN, ya tenemos una caché nativa que cubre nuestras necesidades.

No añadamos otra.

Frameworks JavaScript y runtime del lado del cliente

No estamos construyendo una SPA — estamos construyendo una landing page estática.

Un runtime del lado del cliente que no usamos solo perjudicará el rendimiento.

En este caso no añade coste al sistema ni al desarrollo, pero sí perjudica al producto si es que nos importan las métricas de rendimiento y la experiencia de usuario.

Lo mismo pasa con la hidratación.

Los frameworks modernos de JavaScript aportan mucho valor, pero eso no significa que debamos hidratar toda la página.

Si solo hay unas pocas áreas interactivas, ¿por qué pagar el coste de hidratar la página entera cuando podemos hidratar solo las partes necesarias?

Pues depende del framework.

Si es algo como Astro, que permite hidratación parcial — adelante. El coste es mínimo y el valor es grande. Si es algo como Next.js, que no lo permite — no intentes forzarlo. No vale la pena: el coste y el riesgo superan al beneficio.

Intentemos no añadir runtimes ni hidratación innecesaria.

Frameworks de estilos con runtime en el cliente

No.

No hay más que decir. Simplemente no.

Servicio de build

Este tema es interesante — aunque como siempre, depende de nuestras necesidades y del valor que aporte.

A primera vista, si podemos manejarlo todo con nuestro pipeline de control de versiones, no necesitamos un servicio de build. Así que no hay motivo para construirlo, mantenerlo y monitorizarlo.

Sin embargo, si para construir el sitio necesitamos acceso a datos privados de una base de datos o servicio que no está expuesto públicamente, entonces un servicio de build empieza a tener sentido.

Podríamos exponer un endpoint en ese servicio privado protegido con un secreto… pero eso añade coste y, lo que es más importante, riesgo.

En general, cuantas menos excepciones, mejor — especialmente en temas de seguridad.

No escatimemos recursos en materia de seguridad: el coste de una brecha es mucho mayor que el de un servicio de build.

Añadámoslo.

Back-for-the-front

A veces necesitamos pequeños endpoints API para cubrir necesidades específicas del frontend.

Si podemos usar funciones serverless, perfecto — es uno de sus casos de uso ideales. Si podemos añadir el endpoint a un servicio existente donde tenga sentido, hagámoslo. Si necesitamos crear un nuevo microservicio, Ok, vale.

Pero no debemos desplegar un framework full-stack solo para servir un sitio estático con un par de pequeños endpoints.

Un framework full-stack tiene todo el sobrecoste del SSR, incluso aunque esté sirviendo páginas estáticas y un par de endpoints.

La razón de hacer un sitio totalmente estático era usar el CDN para servir los archivos — usar un framework full-stack contradice esa decisión.

Así que sí, al back-for-the-front, pero sin añadir complejidad innecesaria a un sitio estático.

Añadámoslo (pero sin usar un framework full-stack para servir el sitio estático).