Arquitecturas orientadas al cliente

Estas arquitecturas definen cómo se genera y sirve la interfaz de usuario, y cómo interactúa con el servidor. La distinción clave entre ellas es dónde y cuándo se genera el HTML que ve el usuario.

MPA (Multi-Page Application)

Es el modelo web original. Cada URL corresponde a una página distinta que el servidor genera y sirve completa. Cada navegación implica una recarga completa del navegador.

Tecnologías típicas PHP, Laravel, Django, ASP.NET, Ruby on Rails.

Ventajas:

• Modelo mental simple: una URL = una página.
• Excelente SEO de forma natural. El HTML llega completo al navegador.
• No requiere JavaScript para funcionar.
• Buen rendimiento en la primera carga.

Desventajas:

• Cada navegación recarga toda la página, lo que puede sentirse lento.
• Experiencia de usuario menos fluida comparada con una SPA.
• Difícil compartir lógica entre frontend y backend.

Ideal para sitios de contenido, paneles de administración tradicionales, aplicaciones con poca interactividad.

SPA (Single Page Application) + API REST

El servidor sirve un único HTML prácticamente vacío. JavaScript toma el control y gestiona toda la interfaz en el cliente, comunicándose con el backend exclusivamente a través de una API REST.

Ventajas

• Experiencia de usuario muy fluida, sin recargas de página.
• Separación total entre frontend y backend.
• El mismo backend puede servir a múltiples clientes (web, móvil, etc.).
• Los equipos pueden trabajar de forma independiente.

Desventajas

• SEO complicado por defecto: el HTML inicial está vacío.
• La primera carga puede ser lenta si el bundle de JavaScript es grande.
• Requiere gestionar el estado en el cliente (Redux, Zustand, Pinia...).
• La lógica de autenticación y autorización es más compleja.

Ideal para aplicaciones web con mucha interactividad: dashboards, herramientas internas, apps interactivas tipo Gmail.

JAMstack

Acrónimo de JavaScript, APIs y Markup. El frontend se construye como archivos estáticos (HTML, CSS, JS) que se generan en tiempo de compilación (build) y se sirven desde una CDN global. La funcionalidad dinámica se delega a APIs externas o serverless functions.

Ventajas

• Rendimiento excepcional: los archivos se sirven desde la CDN más cercana al usuario.
• Muy seguro: sin servidor de aplicación expuesto.
• Barato de alojar.
• Excelente para SEO: el HTML llega completo.

Desventajas

• No apto para contenido altamente dinámico o en tiempo real.
• Los tiempos de compilación (build) pueden ser largos en sitios con miles de páginas.
• La interactividad compleja requiere workarounds.

Ideal para blogs, webs de marketing, documentación, e-commerce de catálogo.

SSR (Server-Side Rendering)

Aunque el término describe el mismo proceso que una MPA (renderizar en servidor), en el contexto moderno hace referencia específica a frameworks como Next.js o Nuxt que pre-renderizan en servidor pero luego hidratan la página con JavaScript, convirtiéndola en una SPA.

La diferencia clave con una MPA clásica es la hidratación: el HTML llega completo del servidor (bueno para SEO y primera carga), pero luego JavaScript "reactiva" los componentes y las navegaciones siguientes son fluidas como en una SPA.

Ventajas:

• Excelente SEO: el contenido está en el HTML desde el primer momento.
• Buena experiencia en la primera carga (First Contentful Paint rápido).
• Interactividad rica tras la hidratación.

Desventajas:

• Mayor carga en el servidor que SSG o JAMstack.
• La hidratación puede causar un periodo de página visible pero no interactiva.
• Más complejo de configurar y desplegar que una SPA pura.

Ideal para e-commerce, medios de comunicación, webs que necesitan SEO y contenido dinámico a la vez.

SSG (Static Site Generation)

El HTML se genera en tiempo de build, no en cada petición. Similar a JAMstack, pero haciendo énfasis en el proceso de generación con frameworks como Next.js (modo static), Astro o Hugo.

Diferencia con SSR: en SSG el HTML se genera una sola vez en el build. En SSR se genera en cada petición del usuario.

Ventajas

• Máximo rendimiento: archivos pre-generados servidos desde CDN.
• Sin carga de servidor en tiempo de ejecución.
• Seguro y barato.

Desventajas

• El contenido puede quedarse desactualizado entre builds.
• No sirve para contenido que cambia en tiempo real.
• Builds lentos en sitios con muchas páginas (mitigable con Incremental Static Regeneration).

Ideal para documentación, blogs, webs corporativas, catálogos que no cambian con mucha frecuencia.

Micro-frontends

Aplica los principios de los microservicios al frontend: la interfaz de usuario se divide en fragmentos independientes, cada uno desarrollado, desplegado y mantenido por un equipo distinto.

Ventajas

• Equipos completamente autónomos: tecnología, despliegue y ciclo de vida independientes.
• Fallos aislados: un micro-frontend roto no tumba toda la interfaz.
• Escalable organizativamente para equipos grandes.

Desventajas

• Alta complejidad técnica: comunicación entre fragmentos, estilos compartidos, rendimiento.
• Puede haber duplicidad de dependencias (cada micro-frontend carga su propio React, por ejemplo).
• Experiencia de usuario puede ser inconsistente si no se gobierna bien el diseño.

Ideal para grandes organizaciones con múltiples equipos trabajando sobre el mismo producto (portales bancarios, plataformas SaaS enterprise).

Comparativa de renderizado

	MPA	SPA	SSR	SSG
HTML generado en	Servidor (petición)	Cliente	Servidor (petición)	Build
SEO	✅ Excelente	⚠️ Difícil	✅ Excelente	✅ Excelente
Primera carga	✅ Rápida	⚠️ Lenta	✅ Rápida	✅ Muy rápida
Interactividad	⚠️ Limitada	✅ Alta	✅ Alta	⚠️ Limitada
Contenido dinámico	✅	✅	✅	⚠️
Coste de servidor	Medio	Bajo	Alto	Muy bajo