Una aplicación de página única ( SPA ) es una aplicación web o un sitio web que interactúa con el usuario reescribiendo dinámicamente la página web actual con nuevos datos del servidor web , en lugar del método predeterminado de que un navegador web cargue páginas completamente nuevas. El objetivo son transiciones más rápidas que hagan que el sitio web se parezca más a una aplicación nativa .
En un SPA, nunca se produce una actualización de página; en cambio, todo el código HTML , JavaScript y CSS necesario lo recupera el navegador con una sola carga de página, [1] o los recursos apropiados se cargan dinámicamente y se agregan a la página según sea necesario, generalmente en respuesta a las acciones del usuario.
Los orígenes del término aplicación de una sola página no están claros, aunque el concepto fue discutido al menos ya en 2003 por evangelistas de la tecnología de Netscape. [2] Stuart Morris, un estudiante de programación en la Universidad de Cardiff, Gales, escribió el sitio web independiente slashdotslash.com con los mismos objetivos y funciones en abril de 2002, [3] y más tarde el mismo año Lucas Birdeau, Kevin Hakman, Michael Peachey y Clifford Yeh describieron una implementación de solicitud de una sola página en la patente estadounidense 8.136.109. [4] Las formas anteriores se denominaban aplicaciones web enriquecidas .
JavaScript se puede utilizar en un navegador web para mostrar la interfaz de usuario (UI), ejecutar la lógica de la aplicación y comunicarse con un servidor web. Hay bibliotecas gratuitas maduras disponibles que respaldan la creación de un SPA, lo que reduce la cantidad de código JavaScript que los desarrolladores tienen que escribir.
Hay varias técnicas disponibles que permiten al navegador conservar una sola página incluso cuando la aplicación requiere comunicación con el servidor.
Los autores de HTML pueden aprovechar los ID de elementos para mostrar u ocultar diferentes secciones del documento HTML. Luego, usando CSS, los autores pueden usar el :targetselector de pseudoclase para mostrar solo la sección de la página a la que navegó el navegador.
Los marcos y bibliotecas de JavaScript de los navegadores web, como AngularJS , Ember.js , ExtJS , Knockout.js , Meteor.js , React , Vue.js y Svelte han adoptado principios de SPA. Aparte de ExtJS, todos estos son gratuitos.
A partir de 2006, la técnica más destacada utilizada fue el Ajax . [1] Ajax implica el uso de solicitudes asincrónicas a un servidor para datos XML o JSON , como con XMLHttpRequest de JavaScript o más moderno fetch()(desde 2017), o el obsoleto ActiveX Object . A diferencia del enfoque declarativo de la mayoría de los marcos SPA, con Ajax el sitio web utiliza directamente JavaScript o una biblioteca de JavaScript como jQuery para manipular el DOM y editar elementos HTML. Ajax se ha popularizado aún más gracias a bibliotecas como jQuery , que proporciona una sintaxis más simple y normaliza el comportamiento de Ajax en diferentes navegadores que históricamente tenían un comportamiento variable.
WebSockets es una tecnología de comunicación cliente-servidor bidireccional en tiempo real que forma parte de la especificación HTML. Para la comunicación en tiempo real, su uso es superior al de Ajax en términos de rendimiento [9] y simplicidad.
Los eventos enviados por el servidor (SSE) son una técnica mediante la cual los servidores pueden iniciar la transmisión de datos a los clientes del navegador. Una vez que se ha establecido una conexión inicial, un flujo de eventos permanece abierto hasta que el cliente lo cierra. Los SSE se envían a través de HTTP tradicional y tienen una variedad de características de las que los WebSockets carecen por diseño, como la reconexión automática, ID de eventos y la capacidad de enviar eventos arbitrarios. [10]
Aunque este método está desactualizado, también se pueden lograr llamadas asincrónicas al servidor utilizando tecnologías de complementos del navegador como Silverlight , Flash o subprogramas Java .
Las solicitudes al servidor normalmente dan como resultado datos sin procesar (por ejemplo, XML o JSON ) o la devolución de HTML nuevo. En el caso de que el servidor devuelva HTML, JavaScript en el cliente actualiza un área parcial del DOM ( modelo de objetos de documento ). Cuando se devuelven datos sin procesar, a menudo se usa un proceso JavaScript XML /( XSL ) del lado del cliente (y en el caso de JSON una plantilla ) para traducir los datos sin procesar a HTML, que luego se usa para actualizar un área parcial del DOM. .
Un SPA mueve la lógica del servidor al cliente, y la función del servidor web evoluciona hacia una API o servicio web de datos puros. Este cambio arquitectónico se ha denominado, en algunos círculos, "Arquitectura de servidor delgado" para resaltar que la complejidad se ha trasladado del servidor al cliente, con el argumento de que, en última instancia, esto reduce la complejidad general del sistema.
El servidor mantiene el estado necesario en la memoria del estado del cliente de la página. De esta manera, cuando cualquier solicitud llega al servidor (generalmente acciones del usuario), el servidor envía el HTML y/o JavaScript apropiado con los cambios concretos para llevar al cliente al nuevo estado deseado (generalmente agregando/eliminando/actualizando una parte del cliente DOM). Al mismo tiempo, se actualiza el estado del servidor. La mayor parte de la lógica se ejecuta en el servidor y, por lo general, el HTML también se representa en el servidor. De alguna manera, el servidor simula un navegador web, recibe eventos y realiza cambios delta en el estado del servidor que se propagan automáticamente al cliente.
Este enfoque necesita más memoria y procesamiento del servidor, pero la ventaja es un modelo de desarrollo simplificado porque a) la aplicación generalmente está completamente codificada en el servidor, y b) los datos y el estado de la interfaz de usuario en el servidor se comparten en el mismo espacio de memoria sin Necesidad de puentes de comunicación cliente/servidor personalizados.
Esta es una variante del enfoque del servidor con estado. La página del cliente envía datos que representan su estado actual al servidor, generalmente a través de solicitudes Ajax. Usando estos datos, el servidor puede reconstruir el estado del cliente de la parte de la página que necesita ser modificada y puede generar los datos o código necesarios (por ejemplo, como JSON o JavaScript), que se devuelve al cliente para traer a un nuevo estado, generalmente modificando el árbol DOM de la página de acuerdo con la acción del cliente que motivó la solicitud.
Este enfoque requiere que se envíen más datos al servidor y puede requerir más recursos computacionales por solicitud para reconstruir parcial o totalmente el estado de la página del cliente en el servidor. Al mismo tiempo, este enfoque es más fácilmente escalable porque no se guardan datos de página por cliente en el servidor y, por lo tanto, las solicitudes Ajax se pueden enviar a diferentes nodos del servidor sin necesidad de compartir datos de sesión ni afinidad de servidor.
Algunos SPA se pueden ejecutar desde un archivo local utilizando el esquema URI de archivo . Esto brinda a los usuarios la posibilidad de descargar el SPA desde un servidor y ejecutar el archivo desde un dispositivo de almacenamiento local, sin depender de la conectividad del servidor. Si dicho SPA desea almacenar y actualizar datos, debe utilizar un almacenamiento web basado en navegador . Estas aplicaciones se benefician de los avances disponibles con HTML . [11]
Debido a que SPA es una evolución del modelo de redibujado de páginas sin estado para el que fueron diseñados originalmente los navegadores, han surgido algunos desafíos nuevos. Las posibles soluciones (de diversa complejidad, exhaustividad y control de autor) incluyen: [12]
Debido a la falta de ejecución de JavaScript en los rastreadores de algunos motores de búsqueda web populares , [17] SEO ( optimización de motores de búsqueda ) históricamente ha presentado un problema para los sitios web públicos que desean adoptar el modelo SPA. [18]
Entre 2009 y 2015, Google Webmaster Central propuso y luego recomendó un "esquema de rastreo AJAX" [19] [20] utilizando un signo de exclamación inicial en los identificadores de fragmentos para páginas AJAX#! con estado ( ). El sitio SPA debe implementar un comportamiento especial para permitir la extracción de metadatos relevantes por parte del rastreador del motor de búsqueda. Para los motores de búsqueda que no admiten este esquema de hash de URL , las URL hash del SPA permanecen invisibles. Estos URI "hash-bang" han sido considerados problemáticos por varios escritores, incluida Jeni Tennison en el W3C, porque hacen que las páginas sean inaccesibles para aquellos que no tienen JavaScript activado en su navegador. También rompen los encabezados de referencia HTTP ya que los navegadores no pueden enviar el identificador de fragmento en el encabezado de referencia. [21] En 2015, Google desaprobó su propuesta de rastreo AJAX hash-bang. [22]
Alternativamente, las aplicaciones pueden representar la carga de la primera página en el servidor y las actualizaciones posteriores de la página en el cliente. Esto es tradicionalmente difícil, porque es posible que sea necesario escribir el código de representación en un lenguaje o marco diferente en el servidor y en el cliente. El uso de plantillas sin lógica, la compilación cruzada de un idioma a otro o el uso del mismo idioma en el servidor y el cliente pueden ayudar a aumentar la cantidad de código que se puede compartir.
En 2018, Google introdujo el renderizado dinámico como otra opción para los sitios que deseaban ofrecer a los rastreadores una versión pesada de una página sin JavaScript para fines de indexación. [23] La representación dinámica cambia entre una versión de una página que se representa en el lado del cliente y una versión pre-renderizada para agentes de usuario específicos. Este enfoque implica que su servidor web detecte rastreadores (a través del agente de usuario) y los enrute a un procesador, desde donde luego se les entrega una versión más simple de contenido HTML.
Debido a que la compatibilidad SEO no es trivial en los SPA, vale la pena señalar que los SPA generalmente no se utilizan en un contexto donde la indexación de los motores de búsqueda es un requisito o deseable. Los casos de uso incluyen aplicaciones que muestran datos privados ocultos detrás de un sistema de autenticación . En los casos en que estas aplicaciones son productos de consumo, a menudo se utiliza un modelo clásico de "redibujo de página" para la página de inicio y el sitio de marketing de la aplicación, que proporciona suficientes metadatos para que la aplicación aparezca como un resultado en una consulta de motor de búsqueda. Los blogs, foros de soporte y otros artefactos tradicionales de rediseño de páginas a menudo se encuentran alrededor del SPA y pueden generar motores de búsqueda con términos relevantes.
A partir de 2021 y específicamente con Google, la compatibilidad SEO para un SPA simple es sencilla y requiere que solo se cumplan algunas condiciones simples. [24]
Una forma de aumentar la cantidad de código que se puede compartir entre servidores y clientes es utilizar un lenguaje de plantilla sin lógica como Moustache o Manillares . Estas plantillas se pueden representar desde diferentes lenguajes de host, como Ruby en el servidor y JavaScript en el cliente. Sin embargo, el simple hecho de compartir plantillas normalmente requiere la duplicación de la lógica empresarial utilizada para elegir las plantillas correctas y completarlas con datos. La renderización a partir de plantillas puede tener efectos negativos en el rendimiento cuando solo se actualiza una pequeña parte de la página, como el valor de una entrada de texto dentro de una plantilla grande. Reemplazar una plantilla completa también podría alterar la selección de un usuario o la posición del cursor, mientras que actualizar solo el valor modificado podría no hacerlo. Para evitar estos problemas, las aplicaciones pueden usar enlaces de datos de UI o manipulación granular de DOM para actualizar solo las partes apropiadas de la página en lugar de volver a representar plantillas completas. [25]
Dado que un SPA es, por definición, "una sola página", el modelo rompe el diseño del navegador para la navegación del historial de páginas utilizando los botones "adelante" o "atrás". Esto presenta un impedimento de usabilidad cuando un usuario presiona el botón Atrás, esperando el estado de pantalla anterior dentro del SPA, pero en cambio, se descarga la página única de la aplicación y se presenta la página anterior en el historial del navegador.
La solución tradicional para los SPA ha sido cambiar el identificador del fragmento hash de la URL del navegador de acuerdo con el estado actual de la pantalla. Esto se puede lograr con JavaScript y hace que los eventos del historial de URL se acumulen dentro del navegador. Siempre que el SPA sea capaz de resucitar el mismo estado de la pantalla a partir de la información contenida en el hash de la URL, se conserva el comportamiento esperado del botón Atrás.
Para abordar aún más este problema, la especificación HTML introdujo pushState y replaceState, que brindan acceso programático a la URL real y al historial del navegador.
Las herramientas de análisis como Google Analytics dependen en gran medida de la carga de páginas nuevas completas en el navegador, iniciada por la carga de una nueva página. Los SPA no funcionan de esta manera.
Después de cargar la primera página, todos los cambios posteriores de página y contenido son manejados internamente por la aplicación, que simplemente debería llamar a una función para actualizar el paquete de análisis. Al no llamar a dicha función, el navegador nunca activa la carga de una nueva página, no se agrega nada al historial del navegador y el paquete de análisis no tiene idea de quién está haciendo qué en el sitio.
De manera similar a los problemas encontrados con los rastreadores de motores de búsqueda, las herramientas DAST pueden tener problemas con estas aplicaciones ricas en JavaScript. Los problemas pueden incluir la falta de enlaces de hipertexto, problemas de uso de memoria y recursos cargados por el SPA que normalmente están disponibles a través de una interfaz de programación de aplicaciones o API. Las aplicaciones de una sola página todavía están sujetas a los mismos riesgos de seguridad que las páginas web tradicionales, como Cross-Site Scripting (XSS) , pero también a una serie de otras vulnerabilidades únicas, como la exposición de datos a través de API y la lógica del lado del cliente y la aplicación del lado del cliente. de seguridad del lado del servidor. [26] Para escanear eficazmente una aplicación de una sola página, un escáner DAST debe poder navegar por la aplicación del lado del cliente de manera confiable y repetible para permitir el descubrimiento de todas las áreas de la aplicación y la interceptación de todas las solicitudes que la aplicación envía a servidores remotos (por ejemplo, solicitudes de API).
Es posible agregar eventos de carga de página a un SPA utilizando la API de historial HTML; esto ayudará a integrar la analítica. La dificultad surge en gestionar esto y garantizar que todo se realice con precisión; esto implica verificar si faltan informes y hay entradas dobles. Algunos marcos proporcionan integraciones de análisis gratuitas que abordan la mayoría de los principales proveedores de análisis. Los desarrolladores pueden integrarlos en la aplicación y asegurarse de que todo funcione correctamente, pero no es necesario hacerlo todo desde cero. [25]
Hay algunas formas de acelerar la carga inicial de un SPA, como la representación previa selectiva de la página de inicio/índice del SPA, el almacenamiento en caché y varias técnicas de división de código, incluidos módulos de carga diferida cuando sea necesario. Pero no es posible eludir el hecho de que es necesario descargar el marco, al menos parte del código de la aplicación; y accederá a una API para obtener datos si la página es dinámica. [25] Este es un escenario de compensación de "págame ahora o págame después". La cuestión del rendimiento y los tiempos de espera sigue siendo una decisión que debe tomar el desarrollador.
Un SPA se carga completamente en la carga inicial de la página y luego las regiones de la página se reemplazan o actualizan con nuevos fragmentos de página cargados desde el servidor a pedido. Para evitar la descarga excesiva de funciones no utilizadas, un SPA a menudo descargará progresivamente más funciones a medida que sean necesarias, ya sea pequeños fragmentos de la página o módulos de pantalla completos.
De esta manera existe una analogía entre los "estados" en un SPA y las "páginas" en un sitio web tradicional. Debido a que la "navegación de estado" en la misma página es análoga a la navegación de página, en teoría, cualquier sitio web basado en páginas podría convertirse en una sola página reemplazando en la misma página solo las partes modificadas.
El enfoque SPA en la web es similar a la técnica de presentación de interfaz de documento único (SDI) popular en las aplicaciones de escritorio nativas .
Blaze es una potente biblioteca para crear interfaces de usuario escribiendo plantillas HTML reactivas.
el navegador puede ejecutar JavaScript y producir contenido sobre la marcha; el rastreador no puede
Históricamente, las aplicaciones Ajax han sido difíciles de procesar para los motores de búsqueda porque el contenido Ajax se produce