Multi-Page-Application vs Single-Page Application

A la hora de adentrarnos en el dinámico mundo del desarrollo web resulta casi inevitable encontrarnos con dos términos que se han convertido prácticamente en antagónicos con el paso de los años y que representan dos de las metodologías más utilizadas a la hora de diseñar e implementar nuestras aplicaciones.

Hablamos, por supuesto, de los dos patrones de arquitectura web más utilizados en la actualidad: Multi-Page-Application —en adelante MPA— y Single-Page Application —en adelante SPA—.

El objetivo de este artículo es la realización de un análisis comparativo entre ambas arquitecturas: Single Page Application vs Multi-Page Application.

Y daremos respuesta a preguntas comunes:

• ¿Cómo funciona cada una?
• ¿Qué las diferencia?
• ¿Cuál se adapta más a mi caso de uso?
• ¿Son las SPAs un nuevo trend, o están aquí para quedarse?

• Breve historia del desarrollo de interfaces gráficas
• Single Page Application vs Multi-Page Application
  • Rendimiento MPAs vs. SPAs
  • Seguridad MPAs vs. SPAs
  • SEO MPAs vs. SPAs
  • Infraestructura, desarrollo y mantenimiento
• ¿Single Page Application o Multi-Page Application? Comparación y elección de la mejor arquitectura de software

Desde las primeras aplicaciones web con su, a nuestros ojos, poco atractivo diseño y su tan simplificada experiencia de usuario, hasta las interfaces complejas y cuidadosamente diseñadas de nuestros días, entender la evolución de las diferentes arquitecturas de software de aplicaciones web arroja luz sobre las motivaciones, ventajas e inconvenientes que estas introducen en el proceso de creación de software.

Por tanto, hagamos un pequeño viaje y remontémonos al principio.

Nos encontramos en 1978, en un momento en el que Trygve Reenskaug, mientras trabaja en el lenguaje de programación Smalltalk-80, se enfrenta a un problema bastante específico: ¿Cómo podemos trasladar el modelo mental que un usuario tiene de un conjunto de datos a un modelo digital? ¿Cómo podemos generar en el usuario la ilusión de estar interactuando directamente con la información de dominio? ¿Cómo permitirle manipular gran cantidad de datos de forma sencilla?

La solución resultante de abordar este problema es el patrón Modelo-Vista-Controlador o MVC, una metodología que permite estructurar nuestros proyectos de forma que la lógica de nuestras interfaces y la lógica de dominio queden completamente separadas.

Este concepto, en apariencia simple, resultó altamente efectivo e influyente, muchos de los grandes frameworks del momento —y de la actualidad— adoptaron esta metodología y, en la década de los 90 ya se describía como un paradigma de programación a tener en cuenta. 

Por supuesto, su popularidad dio lugar a variaciones y a revisiones de esta metodología como el patrón MVVM o el MVP, pero todos parten de un principio común: debemos separar la lógica de interfaz de nuestra lógica de negocio.

En este contexto y, en gran parte de los casos, basándose en la metodología MVC o sus variantes, comienzan a desarrollarse aplicaciones web en las que la experiencia de usuario va tomando, poco a poco, mayor relevancia en el proceso de desarrollo.

Las conocidas como MPAs, Multi-Page Applications, se han convertido en la arquitectura de software “tradicional” para el desarrollo de aplicaciones web y representan el principal exponente del uso del patrón MVC para desarrollo de aplicaciones web.

Su principio de funcionamiento es sencillo: un usuario solicita información a un servidor; este procesa la petición y realiza operaciones sobre los datos, devolviendo una vista cuando termina de ejecutar el código. Por tanto, cada acción que el usuario realiza ejecutará una recarga completa de la página a la que se quiere acceder y, por tanto, de la información que se presenta al usuario.

En el otro lado del espectro encontramos las llamadas SPAs Single Page Applications, cuya popularidad ha crecido enormemente en los últimos años. Su innovación es la siguiente: ejecutando el código en el lado del cliente, y no en el servidor, obtenemos la posibilidad de crear webs más dinámicas, capaces de ofrecer interacciones más complejas y evitando la necesidad de recargar la página completamente cuando se realiza cualquier operación.

Después de una carga inicial, en la que nuestro cliente descarga el código de la aplicación, gran parte de las interacciones que realice un usuario dará lugar a una petición AJAX , encargada de actualizar la interfaz con la información que recibe del servidor. Esta información se recibe normalmente en formato JSON de modo que resulte fácil de procesar.

Podemos decir que las SPAs son reactivas, en contraposición con las MPAs, puesto que no requieren de una recarga completa de la vista. Pero ¿A qué se debe este cambio? ¿Qué lo ha hecho posible?

Podemos dividir la respuesta a estas preguntas en tres partes: la creciente importancia de la experiencia de usuario, el rápido desarrollo de las tecnologías frontend y la introducción de nuevas técnicas que facilitan la comunicación asíncrona entre cliente y servidor, como AJAX (Asynchronous Javascript And XML).

AJAX, básicamente, se basa en un conjunto de tecnologías que, utilizando Javascript como hilo conductor, hacen posible este tipo comunicación con el servidor:

• HTML y CSS se utilizan para la capa de presentación.

• Javascript permite manipular el DOM (Document Object Model) para la carga dinámica y la interacción con los datos.

• JSON se ha convertido en el estándar para el intercambio de datos entre cliente y servidor.

• Se utiliza la API XMLHttpRequest para realizar las peticiones al servidor.

Resulta necesario destacar que AJAX debe considerarse como el concepto general de comunicación asíncrona entre cliente y servidor y que, con el paso del tiempo, se han desarrollado nuevas metodologías basadas en esta técnica. Frameworks como React, Angular o Vue utilizan Fetch API, Axios o RxJS para conseguir el mismo resultado.

La evolución del tipo de peticiones entre cliente y servidor — de síncronas a asíncronas — constituye la principal diferencia entre MPAs y SPAs y, a partir de la misma, podemos definir el resto de diferencias de funcionamiento entre ambas arquitecturas así como sus principales ventajas e inconvenientes.

Uno de los puntos más importantes a la hora de comparar Single Page Application vs Multi-Page Application. Objetivamente — y con la definición de cada arquitectura en la mano — puede resultar obvio que obtendremos un rendimiento mejor utilizando la arquitectura SPA, puesto que evitan cargas completas de nuestro código y disminuyen la carga de trabajo en el servidor.

Este razonamiento es completamente cierto, y constituye la gran ventaja de esta arquitectura frente a las tradicionales MPAs. Sin embargo, cuando buscamos información acerca de este tipo de aplicaciones es común que se pase por alto un aspecto de vital importancia a la hora de desarrollar y mantener este tipo de aplicaciones: el tiempo inicial de carga.

Pensemos en ello, sabemos que una SPA básicamente ejecuta la gran parte del código que la constituye en el cliente por lo que, en algún punto del proceso, el cliente descargará este código para poder ejecutarlo.

Y en este punto nos enfrentamos al problema, al descargar el código y ejecutarlo en el cliente, obtenemos un mejor rendimiento cuando el usuario realice acciones en nuestra página. Sin embargo, si esta descarga es muy lenta, impactará negativamente en el rendimiento — retrasando el tiempo que tarda en ser interactiva — y, por consiguiente, con la experiencia de nuestros usuarios. Algo paradójico ¿Verdad?

Las causas son variadas, y podríamos escribir un artículo completo sobre ellas, pero pueden resumirse en los siguientes puntos:

• Tamaño de descarga: resulta indispensable optimizar el tamaño del código que debe descargar el cliente para evitar un alto tiempo de carga inicial. Más código a descargar es igual a más tiempo de carga. Técnicas como minifying, compresión, refactoring y caching pueden ayudar a la optimización.
• Análisis, compilación y ejecución: uno de los mayores costes a la hora de inicializar nuestras aplicaciones, puesto que afecta directamente al tiempo que tarda la aplicación en ser interactiva tras la descarga.

El tipo de dispositivo de nuestros usuarios es muy importante, los dispositivos con menos potencia de procesado tardarán más en cargar la aplicación, lo que se hace dolorosamente evidente en dispositivos móviles.

Reducir el código necesario para ejecutar diversas partes de nuestra aplicación ayuda a mejorar esta métrica, dividiéndolo en pequeños bloques, eliminando código que no sea crítico para la ejecución, utilizando el patrón PRPL, etc.

Existen otras herramientas para poder paliar esta desventaja como server-side rendering que también puede afectar positivamente al SEO, como veremos más adelante.

En conclusión  — y de forma general — ¿Utilizando SPA se obtienen aplicaciones más rápidas? Sí. ¿Son las SPA la bala de plata definitiva cuando hablamos de rendimiento de aplicaciones web? No siempre.

Así como el rendimiento, por la propia naturaleza de la arquitectura, es una de las ventajas de las SPAs, la seguridad constituye una de las principales ventajas de las MPAs.

Ejecutar todo el código en el servidor añade un extra de seguridad que una SPA, al exponer su código en el cliente, no ofrece de forma predeterminada.

Por tanto, encontramos que una aplicación MPA es menos susceptible a vulnerabilidades que puedan ser explotadas por terceras partes y hace que, durante el desarrollo de SPAs, debamos prestar más atención a la hora de implementar nuevas features y realizar mantenimientos, consumiendo un tiempo extra que, en ingeniería del software, siempre equivale a un incremento de los costes.

Entre los principales riesgos que presenta la ejecución de código en el cliente podemos destacar:

• Ataques XSS (Cross-site scripting): se producen cuando el atacante es capaz de ejecutar su propio código en nuestra aplicación, obteniendo información sensible.
• Ataques CSRF (Cross-Site Request Forgery): si un ataque XSS permite al atacante ejecutar código en nuestra SPA un ataque CSRF permite al atacante engañar al usuario para ejecutar acciones y obtener información que luego utilizará para ganar acceso a nuestro sistema.

Como norma general, cualquier dato que se genere en nuestro cliente es susceptible de haber sido manipulado, por lo que siempre debemos prestar atención cuando gestionamos e introducimos dichos datos a nuestro sistema.

Por lo general tanto para MPAs como para SPAs pondremos el foco en la utilización de protocolos como HTTPS, la inclusión de los response headers correctos y la configuración adecuada de los diferentes privilegios de acceso a información, entre otros métodos para asegurar la seguridad.

Pero, en concreto, si hablamos de SPAs, debemos poner especial atención en los procesos de autenticación y autorización de usuarios para el acceso a nuestras APIs:

• Limitando el alcance de acceso de los session tokens.
• Limitando el tiempo de validez de los tokens.
• Utilizando formatos de token que no expongan información de nuestros usuarios.
• Delegando, en la medida de lo posible, las rutinas de autenticación y acceso en el servidor, limitando la cantidad de información sensible almacenada en el navegador (Token Handler Pattern).

La problemática de una SPA a la hora de posicionarla en los buscadores es sencilla: ¿Si sólo disponemos de un archivo HTML que cambia dinámicamente con la interacción del usuario, cómo pueden los principales buscadores indexar las diferentes páginas de nuestra aplicación?

Estas páginas, literalmente, no existen como tal a la hora de indexarlas, puesto que el responsable de generar la información a mostrar es el cliente. Algo se resuelve fácilmente en una MPA puesto que, para cada página de contenido, se sirve código HTML estático con la información que recibirá el usuario.

Podría parecer que las MPAs se han anotado otro punto, pero la respuesta no es tan sencilla. Existe una solución que permite facilitar el posicionamiento SEO de una SPA: el server-side rendering.

Server-side rendering

Aunque buscadores como Google son capaces de ejecutar algo de Javascript para entender el contenido de nuestras aplicaciones, no suele resultar suficiente en el caso de la SPAs, por lo que debemos invertir tiempo y esfuerzo en implementar soluciones que nos permitan beneficiarnos de lo mejor de los dos mundos.

¿En qué consiste esta solución? Básicamente, implementaremos un sistema que nos permita generar código HTML para cada ruta de nuestra aplicación, sobre el cual ejecutaremos código JS que proporcionará el comportamiento de una SPA.

En esencia, nuestro servidor devuelve el DOM inicial para la página solicitada y, mediante un proceso llamado hidratación — hydration según la terminología en inglés —, asociamos este código a un DOM virtual que manipula nuestro código JS.

Con este objetivo nacen iniciativas como Angular Universal, NextJS o la muy interesante Inertia.js, que permiten reducir el tiempo invertido en la implementación de estos sistemas o complementar nuestras aplicaciones back-end para obtener el comportamiento de una SPA.

En el proceso de elección de Single Page Application vs Multi-Page Application, no podemos dejar de lado uno de los aspectos claves, no solo del aspecto técnico de nuestra aplicación, sino de la aplicación como producto de software.

Cuestiones cómo el coste de infraestructura — técnico y monetario —, la experiencia y requerimientos de desarrollo que se necesitarán para crear el producto y el diseño general del sistema resultan clave a la hora de tomar decisiones que resulten en un gran producto. 

Ilustremos este apartado con un ejemplos más concreto:

Cabe destacar que, en términos de infraestructura de software, podemos encontrar tantas implementaciones cómo situaciones y necesidades específicas tenga cada proyecto, con pequeños detalles de comunicación, escalabilidad, seguridad, y mantenimiento que escapan del objetivo de este artículo. 

Pero podemos utilizar este ejemplo sencillo para destacar ciertas características que nos permiten esclarecer las implicaciones de infraestructura y recursos de cada arquitectura.

Teóricamente, la implementación de una MPA —equivalente a nuestro ejemplo— no presentaría grandes diferencias en cuanto a tecnologías utilizadas y configuración de la infraestructura. En este aspecto, resulta difícil establecer una diferenciación entre ambas arquitecturas pues dependerá enteramente de las características de nuestro proyecto.

Entonces, ¿Cuál es la principal diferencia? La respuesta, como no, es JavaScript.

Tanto si optamos por un servidor dedicado para nuestra SPA, que se conecta a nuestras APIs para obtener información, decidimos construir una SPA monolito, creamos una MPA utilizando Django o implementamos una solución híbrida con Livewire o Inertia.js, el estándar para la ejecución de código en el lado del cliente es JS. 

En el momento en el que resulta necesario implementar flujos de usuario con interacciones más complejas del lado del cliente, comenzaremos a ahondar en las interesantes profundidades de este lenguaje — o sus derivados, como Typescript —. 

En el caso de una aplicación SPA necesitaremos hacer uso de una serie de conocimientos extra en frameworks basados en JS como Angular, React o Vue, conocimientos extra de seguridad y comunicación asíncrona entre las diferentes partes de nuestro sistema, técnicas más complejas como server-side rendering, etc. Por lo que incrementamos el número de elementos y tecnologías a gestionar a la hora de crear nuestras aplicaciones.

Esta complejidad añadida siempre se traduce en un aumento de costes. En ingeniería del software, el tiempo es dinero por lo que un sistema más complejo requerirá de un mayor presupuesto, mano de obra especializada y, en general, una mayor inversión en infraestructura e investigación para poder obtenerun producto que cumpla con los objetivos y requerimientos.

A estas alturas del artículo ya debemos estar preguntándonos: ¿Debo utilizar SPA a la hora de desarrollar mi aplicación?

Y, como suele suceder en el mundo del software, la respuesta es: depende. Veamos un pequeño resumen de lo que hemos aprendido hasta el momento:

Como norma general y referente a Single Page Application vs Multi-Page Application, podemos concluir que:

• Utilizar la arquitectura SPA para nuestras aplicaciones puede resultar beneficioso si necesitamos de una experiencia de usuario superior, tanto en velocidad como en interactividad y si realmente podemos obtener un beneficio al asumir la complejidad extra que su desarrollo y mantenimiento conlleva.
• Por otra parte, utilizaremos MPA si el posicionamiento SEO es importante para nuestro producto, como en sistemas enfocados en contenido como sitios de noticias o blogs puesto que obtendremos un sistema simple para organizar la información. También nos beneficiaremos de MPA si necesitamos una seguridad robusta en nuestra aplicación y si la compatibilidad con dispositivos y navegadores más antiguos es una prioridad.

En cualquier caso, siempre debemos tener claro que los requerimientos de nuestro proyecto determinarán nuestra decisión. 

Cada proyecto es un mundo, cada tecnología presenta ventajas y desventajas y siempre es fácil caer en nuevas tendencias o quedar cegados por la nueva y brillante solución que nos presentan los líderes de la industria.

Nuestro trabajo como ingenieros de software es el de tratar de obtener la mayor cantidad de información posible, trasladar las características específicas de nuestros proyectos a requerimientos bien definidos y, solucionado este paso, decidir qué tecnologías, metodologías y recursos utilizamos para implementar la mejor solución posible — y, a poder ser, evitar posibles problemas que nos hagan arrepentirnos de aquel despliegue inofensivo que hicimos un viernes—.

Si buscas más contenido de este tipo puedes visitar nuestro blog o el apartado de los LambdaCast – nuestro podcast de tecnología.