SPA, un paradigma de Arquitectura de Aplicaciones Web en auge

Dentro del desarrollo de aplicaciones web hay una tendencia importante a las denominadas SPA, Single Page Apps. Uno de los principales objetivos es conseguir una mejora importante en la experiencia de usuario: La mejora de los tiempos de espera o latencia entre vistas (similar a las aplicaciones nativas).

En esencia los motivos de las ventajas de las SPAs son sencillos, aunque creo que conviene ponerlo un poco en contexto.

¿Qué diferencia hay respecto a aplicaciones web clásicas?

Habitualmente la lógica de negocio (el código ejecutable) de aplicaciones web se realiza íntegramente en el lado del servidor, y se confía la propia naturaleza del sistema de URLs el mostrar una “vista de aplicación” u otra. Por ej. en un e-commerce el carrito estará en una URL concreta, mientras que la pantalla de login estará bajo otra URL totalmente diferente. Para el navegador, cada URL diferente es completamente independiente del resto: Aunque tenga los mismos estilos y/o plantillas, estos tienen que volver a ser procesados desde cero. Esto, para la gran mayoría de páginas web dinámicas, implica que al cambiar entre vistas se sufrirá el problema de la latencia en la web (artículo de Ilya Grigorik, developer advocate de Google).

Otra característica negativa de esta arquitectura es que el estado de la aplicación del cliente es difícil de mantener, teniendo que hacer auténticos malabarismos para poder gestionar una simple transferencia de información de una vista a otra: Bien lo sabe aquel programador que haya tenido que implementar el típico asistente que se compone de diversas vistas, por ejemplo.

¿Podríamos encontrar más pegas? Puede, pero no es el objetivo. Es más, el sistema REST y URLs tiene mucho sentido y aporta muchas otras ventajas desde la misma arquitectura de servicios web (no interficies) hasta el facilitar el lado humano de compartir un recurso vía un enlace, aunque en ciertos aspectos juegue en nuestra contra.

Arquitectura básica de una SPA

En esencia una SPA es la interfaz de la aplicación web implementada casi íntegramente en el navegador (en lenguaje Javascript actualmente), aunque como toda página web tenga una base importante de HTML y CSS.

Todas las vistas de la interfaz de la aplicación están contenidas en la SPA, realizando una única carga inicial y potencialmente solo posponiendo recursos pesados: Grandes cantidades de datos, Imágenes, videos, …

Por tanto con las SPAs eliminamos por completo uno de los principales cuellos de botella: El problema de la latencia (ver artículo de Grigorik). Así podemos conseguir que la aplicación web alcance la velocidad de cualquier aplicación nativa en lo que se refiere al tiempo de espera al cambiar de vistas. Esto se aprecia notablemente sea cual sea el dispositivo, aunque especialmente cuando se utilizan dispositivos móviles.

A su vez, podemos ahorrar mucho ancho de banda y tiempo de proceso de cálculo (en servidor y cliente) si gestionamos el estado de la aplicación desde el cliente con una SPA: Por ejemplo, la SPA del típico e-commerce al cambiar de vista podría mantener en memoria el estado del carrito de compras y no tener que transferir constantemente esa información en el servidor (por supuesto esa información conviene que esté también en el servidor, pero una cosa no está reñida con la otra).

HTML5 y SPAs

Sin lugar a dudas técnicamente se pueden crear SPAs bajo los estándares de HTML4, por tanto dando cobertura a la totalidad de navegadores utilizados hoy en día que tengan soporte de HTML y Javascript.

Sin embargo, algunas APIs incorporadas en el marco de HTML5 aportan soluciones a ciertos retos bastante específicos de las SPAs:

  • HTML5 History API: Las URLs clásicas eran un problema para las SPAs hasta cierto punto, aunque eso ya no ocurre gracias a esta API. Esto a su vez simplificaría en buena medida el problema de SEO (a pesar de otros intentos de Google como el AJAX Crawling) ya que con PhantomJS en tu servidor puedes renderizar una URL concreta de tu SPA.
  • HTML5 Application Cache: Si consigues sacarle partido a esta API puedes conseguir que tu aplicación funcione incluso cuando el dispositivo cliente está sin conexión a Internet. Toda una killer feature de las SPA como bien apunta Jakub Mrozek en su charla para la WebExpo 2013.

Herramientas

Hay muchas herramientas para desarrollar SPA. Por mencionar alguna, AngularJS tiene entre otros muchos objetivos crear aplicaciones SPA y a su vez mantener las ventajas del sistema de URLs.

Como este tipo de aplicaciones son bastante complejas (comparado con el uso previo de Javascript), es mejor realizarlas de forma estructurada a partir de un framework como Angular, siguiendo paradigmas de diseño de software similares a MVC.

Como apoyo también hay otras herramientas complementarias que ayudan enormemente durante el workflow de trabajo para desarrollar y paquetizar la aplicación: Yeoman, Grunt, Bower son solo la punta del iceberg de un ecosistema creado alrededor de node.js.