Aplicación de página única: ventajas y desventajas [cerrado]

He leído sobre SPA y sus ventajas. La mayoría de ellos me parecen poco convincentes. Hay 3 ventajas que despiertan mis dudas.

Pregunta: ¿Puede actuar como defensor de SPA y demostrar que estoy equivocado acerca de las primeras tres declaraciones?

                              === ADVANTAGES ===

1. SPA es extremadamente bueno para sitios muy receptivos:

La representación del lado del servidor es difícil de implementar para todos los estados intermedios: los estados de vista pequeña no se asignan bien a las URL.

Las aplicaciones de una sola página se distinguen por su capacidad de volver a dibujar cualquier parte de la interfaz de usuario sin requerir un viaje de ida y vuelta del servidor para recuperar HTML. Esto se logra separando los datos de la presentación de datos al tener una capa de modelo que maneja los datos y una capa de vista que lee de los modelos.

¿Qué tiene de malo mantener una capa de modelo para no SPA? ¿SPA es la única arquitectura compatible con MVC en el lado del cliente?

2. Con SPA no necesitamos usar consultas adicionales al servidor para descargar páginas.

Hah, y ¿cuántas páginas puede descargar el usuario durante su visita a su sitio? ¿Dos tres? En cambio, aparecen otros problemas de seguridad y necesita separar su página de inicio de sesión, página de administración, etc. en páginas separadas. A su vez, entra en conflicto con la arquitectura SPA.

3. ¿Puede haber alguna otra ventaja? No escuche nada más ...

                            === DISADVANTAGES ===

1. El cliente debe habilitar javascript.
2. Solo un punto de entrada al sitio.
3. Seguridad.

PD : He trabajado en proyectos SPA y no SPA. Y estoy haciendo esas preguntas porque necesito profundizar mi comprensión. No significa dañar a los partidarios del SPA. No me pidas que lea un poco más sobre SPA. Solo quiero escuchar tus consideraciones al respecto.

Veamos uno de los sitios de SPA más populares, GMail.

1. SPA es extremadamente bueno para sitios muy receptivos:

La representación del lado del servidor no es tan difícil como solía ser con técnicas simples como mantener un #hash en la URL, o más recientemente HTML5pushState . Con este enfoque, el estado exacto de la aplicación web se incrusta en la URL de la página. Como en GMail cada vez que abre un correo, se agrega una etiqueta hash especial a la URL. Si se copia y pega en otra ventana del navegador, puede abrir exactamente el mismo correo (siempre que puedan autenticarse). Este enfoque se asigna directamente a una cadena de consulta más tradicional, la diferencia está simplemente en la ejecución. Con HTML5 pushState () puede eliminar #hashy usar URL completamente clásicas que pueden resolverse en el servidor en la primera solicitud y luego cargar a través de ajax en solicitudes posteriores.

2. Con SPA no necesitamos usar consultas adicionales al servidor para descargar páginas.

¿El número de páginas que el usuario descarga durante la visita a mi sitio web? realmente cuántos correos leen algunas lecturas cuando abre su cuenta de correo. Leí> 50 de una vez. ahora la estructura de los correos es casi la misma. Si va a utilizar un esquema de representación del lado del servidor, el servidor lo representará en cada solicitud (caso típico). - preocupación de seguridad: debe / no debe mantener páginas separadas para los administradores / inicio de sesión que dependen completamente de la estructura de su sitio, tome paytm.com, por ejemplo, también hacer un sitio web SPA no significa que abra todos los puntos finales para todos los usuarios quiero decir que uso formularios de autenticación con mi sitio web de spa. - en el marco de SPA probablemente más utilizado, Angular JS, el desarrollador puede cargar todo el templo html desde el sitio web para que se pueda hacer dependiendo del nivel de autenticación de los usuarios. precargar html para todos los tipos de autenticación no es

3. ¿Puede haber alguna otra ventaja? No escuche nada más ...

• En estos días, puede asumir con seguridad que el cliente tendrá navegadores habilitados para JavaScript.
• Solo un punto de entrada al sitio. Como mencioné anteriormente, es posible el mantenimiento del estado, puede tener cualquier número de puntos de entrada que desee, pero debe tener uno con seguridad.
• incluso en un usuario de SPA solo ve lo que tiene los derechos adecuados. no tienes que inyectar todo a la vez. cargar plantillas html diff y javascript async también es una parte válida de SPA.

Las ventajas que se me ocurren son:

1. La representación de HTML obviamente requiere algunos recursos ahora que cada usuario que visita su sitio está haciendo esto. Además, no solo la representación de las principales lógicas ahora se realiza del lado del cliente en lugar del lado del servidor.
2. problemas de fecha y hora: solo le doy al cliente la hora UTC es un formato preestablecido y ni siquiera me importan las zonas horarias que dejo que JavaScript lo maneje. Esto es una gran ventaja en donde tuve que adivinar las zonas horarias basadas en la ubicación derivada de la IP de los usuarios.
3. para mí, el estado se mantiene mejor en un SPA porque una vez que ha establecido una variable, sabe que estará allí. esto da la sensación de desarrollar una aplicación en lugar de una página web. Esto generalmente ayuda mucho en la creación de sitios como foodpanda, flipkart, amazon. porque si no está utilizando el estado del lado del cliente, está utilizando sesiones costosas.
4. los sitios web seguramente son extremadamente receptivos. Tomaré un ejemplo extremo para este intento de hacer una calculadora en un sitio web que no sea SPA (sé que es extraño).

Actualizaciones de comentarios

No parece que alguien haya mencionado sobre enchufes y sondeos largos. Si cierra la sesión desde otro cliente, por ejemplo, la aplicación móvil, su navegador también debería cerrar sesión. Si no usa SPA, debe volver a crear la conexión de socket cada vez que haya una redirección. Esto también debería funcionar con cualquier actualización en datos como notificaciones, actualización de perfil, etc.

Una perspectiva alternativa: además de su sitio web, ¿su proyecto incluirá una aplicación móvil nativa? En caso afirmativo, lo más probable es que alimente datos sin procesar a esa aplicación nativa desde un servidor (es decir, JSON) y realice un procesamiento del lado del cliente para procesarlo, ¿correcto? Entonces, con esta afirmación, YA estás haciendo un modelo de representación del lado del cliente. Ahora la pregunta es, ¿por qué no debería usar el mismo modelo para la versión del sitio web de su proyecto? Un poco obvio. Luego, la pregunta es si desea renderizar páginas del lado del servidor solo para los beneficios de SEO y la conveniencia de URL compartibles / marcables

Soy pragmático, por lo que trataré de ver esto en términos de costos y beneficios.

Tenga en cuenta que por cualquier desventaja que doy, reconozco que son solucionables. Es por eso que no veo nada en blanco y negro, sino costos y beneficios.

Ventajas

• Seguimiento de estado más fácil: no es necesario usar cookies, envío de formularios, almacenamiento local, almacenamiento de sesión, etc. para recordar el estado entre 2 cargas de página.
• El contenido de la placa de caldera que se encuentra en cada página (encabezado, pie de página, logotipo, banner de copyright, etc.) solo se carga una vez por sesión típica del navegador.
• Sin latencia general al cambiar de "páginas".

Desventajas

• Supervisión del rendimiento: manos a la obra: la mayoría de las soluciones de supervisión del rendimiento a nivel de navegador que he visto se centran exclusivamente en el tiempo de carga de la página, como el tiempo para el primer byte, el tiempo para crear DOM, el viaje de ida y vuelta de red para el HTML, el evento de carga, etc. Actualización de la página post-carga a través de AJAX no se mediría. Hay soluciones que le permiten instrumentar su código para registrar medidas explícitas, como al hacer clic en un enlace, iniciar un temporizador, luego finalizar un temporizador después de mostrar los resultados de AJAX y enviar esos comentarios. New Relic, por ejemplo, admite esta funcionalidad. Al usar un SPA, se ha limitado a unas pocas herramientas posibles.
• Pruebas de seguridad / penetración: manos atadas: los escaneos de seguridad automatizados pueden tener dificultades para descubrir enlaces cuando toda su página se construye dinámicamente mediante un marco de SPA. Probablemente hay soluciones para esto, pero de nuevo, te has limitado.
• Agrupación: es fácil entrar en una situación cuando está descargando todo el código necesario para todo el sitio web en la carga de la página inicial, lo que puede funcionar terriblemente para conexiones de bajo ancho de banda. Puede agrupar sus archivos JavaScript y CSS para intentar cargarlos en fragmentos más naturales a medida que avanza, pero ahora necesita mantener esa asignación y observar si los archivos no deseados se introducen a través de dependencias no realizadas (me sucedió a mí). De nuevo, solucionable, pero con un costo.
• Refactorización de Big Bang: si desea realizar un cambio arquitectónico importante, como por ejemplo, cambiar de un marco a otro, para minimizar el riesgo, es conveniente realizar cambios incrementales. Es decir, comience a usar lo nuevo, migre de alguna manera, como por página, por función, etc., y luego elimine el anterior. Con la aplicación tradicional de varias páginas, puede cambiar una página de Angular a Reaccionar, y luego cambiar otra página en el próximo sprint. Con un SPA, es todo o nada. Si desea cambiar, debe cambiar toda la aplicación de una vez.
• Complejidad de la navegación: las herramientas existen para ayudar a mantener el contexto de navegación en los SPA, como history.js, Angular 2, la mayoría de los cuales se basan en el marco de URL (#) o en la API de historial más reciente. Si cada página era una página separada, no necesita nada de eso.
• Complejidad de descifrar el código: naturalmente pensamos en los sitios web como páginas. Una aplicación de varias páginas generalmente divide el código por página, lo que ayuda a la mantenibilidad.

Nuevamente, reconozco que cada uno de estos problemas es solucionable, a algún costo. Pero llega un punto en el que pasa todo su tiempo resolviendo problemas que podría haber evitado en primer lugar. Se trata de los beneficios y de lo importantes que son para usted.

Desventajas

1. El cliente debe habilitar javascript.Sí, esta es una clara desventaja de SPA. En mi caso, sé que puedo esperar que mis usuarios tengan habilitado JavaScript. Si no puede, entonces no puede hacer un SPA, punto. Eso es como tratar de implementar una aplicación .NET en una máquina sin .NET Framework instalado.

2. Solo un punto de entrada al sitio. Soluciono este problema usando SammyJS . 2-3 días de trabajo para configurar su enrutamiento correctamente, y las personas podrán crear marcadores de enlace profundo en su aplicación que funcionen correctamente. Su servidor solo necesitará exponer un punto final: el punto final "deme el HTML + CSS + JS para esta aplicación" (piense en ello como una ubicación de descarga / actualización para una aplicación precompilada) y el JavaScript del lado del cliente que escriba manejar la entrada real en la aplicación.

3. Seguridad.Este problema no es exclusivo de los SPA, tiene que lidiar con la seguridad exactamente de la misma manera cuando tiene una aplicación cliente-servidor "de la vieja escuela" (el modelo HATEOAS de usar Hipertexto para vincular entre páginas). Es solo que el usuario está haciendo las solicitudes en lugar de su JavaScript, y que los resultados están en HTML en lugar de JSON o algún formato de datos. En una aplicación que no es SPA, debe proteger las páginas individuales en el servidor, mientras que en una aplicación SPA debe proteger los puntos finales de datos. (Y, si no desea que su cliente tenga acceso a todo el código, también debe dividir el JavaScript descargable en áreas separadas. Simplemente lo relaciono con mi sistema de enrutamiento basado en SammyJS para que el navegador solo solicite cosas a las que el cliente sabe que debería tener acceso, en función de una carga inicial de los roles del usuario,

Ventajas

1. Una gran ventaja arquitectónica de un SPA (que rara vez se menciona) en muchos casos es la gran reducción en el "chattiness" de su aplicación. Si lo diseña correctamente para manejar la mayoría del procesamiento en el cliente (el punto completo, después de todo), entonces el número de solicitudes al servidor (lea "posibilidades de errores 503 que arruinan su experiencia de usuario") se reduce drásticamente. De hecho, un SPA hace posible el procesamiento completamente fuera de línea, lo cual es enorme en algunas situaciones.

2. El rendimiento es ciertamente mejor con la representación del lado del cliente si lo hace correctamente, pero esta no es la razón más convincente para construir un SPA. (Las velocidades de red están mejorando, después de todo). No defienda el SPA solo sobre esta base.

3. La flexibilidad en su diseño de interfaz de usuario es quizás la otra gran ventaja que he encontrado. Una vez que definí mi API (con un SDK en JavaScript), pude reescribir completamente mi interfaz con cero impacto en el servidor, aparte de algunos archivos de recursos estáticos. ¡Intenta hacerlo con una aplicación MVC tradicional! :) (Esto se vuelve valioso cuando tiene que preocuparse por las implementaciones en vivo y la coherencia de la versión de su API).

En resumen: si necesita un procesamiento fuera de línea (o al menos quiere que sus clientes puedan sobrevivir a interrupciones ocasionales del servidor), reduciendo drásticamente sus propios costos de hardware, y puede asumir JavaScript y navegadores modernos, entonces necesita un SPA. En otros casos, es más una compensación.

Una desventaja importante de SPA - SEO. Recientemente, Google y Bing comenzaron a indexar páginas basadas en Ajax ejecutando JavaScript durante el rastreo, y aún en muchos casos las páginas se indexan incorrectamente.

Durante el desarrollo de SPA, se verá obligado a manejar los problemas de SEO, probablemente mediante el procesamiento posterior de todo su sitio y la creación de instantáneas html estáticas para el uso del rastreador. Esto requerirá una inversión sólida en infraestructuras adecuadas.

Actualización 19.06.16:

Desde que escribí esta respuesta hace un tiempo, obtengo mucha más experiencia con aplicaciones de una sola página (concretamente, AngularJS 1.x), por lo que tengo más información para compartir.

En mi opinión, la principal desventaja de las aplicaciones de SPA es el SEO, que las limita al tipo de aplicaciones de "tablero" solamente. Además, tendrá un momento mucho más difícil con el almacenamiento en caché, en comparación con las soluciones clásicas. Por ejemplo, en ASP.NET el almacenamiento en caché es extremadamente fácil: simplemente active OutputCaching y estará bien: toda la página HTML se almacenará en caché de acuerdo con la URL (o cualquier otro parámetro). Sin embargo, en SPA deberá manejar el almacenamiento en caché usted mismo (mediante el uso de algunas soluciones como caché de segundo nivel, almacenamiento en caché de plantillas, etc.).

Me gustaría argumentar que SPA es el mejor para aplicaciones basadas en datos. gmail, por supuesto, se trata de datos y, por lo tanto, es un buen candidato para un SPA.

Pero si su página es principalmente para mostrar, por ejemplo, una página de términos de servicio, entonces un SPA es completamente exagerado.

Creo que el punto óptimo es tener un sitio con una mezcla de páginas de estilo SPA y estáticas / MVC, dependiendo de la página en particular.

Por ejemplo, en un sitio que estoy construyendo, el usuario aterriza en una página de índice MVC estándar. Pero luego, cuando van a la aplicación real, llama al SPA. Otra ventaja de esto es que el tiempo de carga del SPA no está en la página de inicio, sino en la página de la aplicación. El tiempo de carga en la página de inicio podría ser una distracción para los usuarios del sitio por primera vez.

Este escenario es un poco como usar Flash. Después de algunos años de experiencia, el número de sitios Flash solo se redujo a casi cero debido al factor de carga. Pero como componente de la página, todavía está en uso.

Para empresas como google, amazon, etc., cuyos servidores funcionan a su capacidad máxima en modo 24/7, reducir el tráfico significa dinero real: menos hardware, menos energía, menos mantenimiento. Cambiar el uso de la CPU del servidor al cliente vale la pena, y los SPA brillan. Las ventajas sobrepeso desventajas de lejos. Entonces, SPA o no SPA depende mucho del caso de uso.

Solo por mencionar otro caso de uso para SPAs, probablemente no tan obvio (para desarrolladores web): actualmente estoy buscando una manera de implementar GUI en sistemas integrados y la arquitectura basada en navegador me parece atractiva. Tradicionalmente, no había muchas posibilidades de interfaz de usuario en sistemas integrados: Java, Qt, wx, etc. o marcos comerciales de propiedad. Hace algunos años, Adobe intentó ingresar al mercado con flash, pero parece no tener tanto éxito.

Hoy en día, como los "sistemas integrados" son tan potentes como los mainframes hace algunos años, una interfaz de usuario basada en navegador conectada a la unidad de control a través de REST es una posible solución. La ventaja es la gran paleta de herramientas para la interfaz de usuario sin costo alguno. (por ejemplo, Qt requiere 20-30 $ por unidad vendida en regalías, más 3000-4000 $ por desarrollador)

Para dicha arquitectura, el SPA ofrece muchas ventajas, por ejemplo, un enfoque de desarrollo más familiar para los desarrolladores de aplicaciones de escritorio, acceso reducido al servidor (a menudo en la industria automotriz, la interfaz de usuario y los problemas del sistema son hardware separado, donde la parte del sistema tiene un sistema operativo RT).

Como el único cliente es el navegador integrado, las desventajas mencionadas como la disponibilidad de JS, el registro del lado del servidor y la seguridad ya no cuentan.

2. Con SPA no necesitamos usar consultas adicionales al servidor para descargar páginas.

Todavía tengo que aprender mucho, pero desde que empecé a aprender sobre SPA, me encantan.

Este punto en particular puede hacer una gran diferencia.

En muchas aplicaciones web que no son SPA, verá que aún recuperarán y agregarán contenido a las páginas que realizan solicitudes ajax. Entonces, creo que SPA va más allá al considerar: ¿qué pasa si el contenido que se va a recuperar y mostrar usando ajax es toda la página? y no solo una pequeña porción de una página?

Déjame presentarte un escenario. Considera que tienes 2 páginas:

1. una página con la lista de productos
2. una página para ver los detalles de un producto específico

Considera que estás en la página de la lista. Luego hace clic en un producto para ver los detalles. La aplicación del lado del cliente activará 2 solicitudes ajax:

1. una solicitud para obtener un objeto json con los detalles del producto
2. una solicitud para obtener una plantilla html donde se insertarán los detalles del producto

Luego, la aplicación del lado del cliente insertará los datos en la plantilla html y los mostrará.

Luego vuelve a la lista (no se hace ninguna solicitud para esto) y abre otro producto. Esta vez, solo habrá una solicitud ajax para obtener los detalles del producto. La plantilla html será la misma, por lo que no es necesario volver a descargarla.

Puede decir que en un no SPA, cuando abre los detalles del producto, realiza solo 1 solicitud y en este escenario hicimos 2. Sí. Pero obtienes la ganancia desde una perspectiva general, cuando navegas por muchas páginas, el número de solicitudes será menor. Y los datos que se transfieren entre el lado del cliente y el servidor también serán más bajos porque las plantillas html se reutilizarán. Además, no es necesario descargar en todas las solicitudes todos esos archivos CSS, imágenes y JavaScript que están presentes en todas las páginas.

Además, consideremos que el lenguaje del lado del servidor es Java. Si analiza las 2 solicitudes que mencioné, 1 descarga datos (no necesita cargar ningún archivo de vista y llamar al motor de representación de vistas) y las otras descargas y la plantilla estática html para que pueda tener un servidor web HTTP que pueda recuperar directamente sin tener que llamar al servidor de aplicaciones Java, ¡no se realiza ningún cálculo!

Finalmente, las grandes empresas están utilizando SPA: Facebook, GMail, Amazon. No juegan, tienen los mejores ingenieros que estudian todo esto. Entonces, si no ve las ventajas, inicialmente puede confiar en ellas y esperar descubrirlas en el futuro.

Pero es importante utilizar buenos patrones de diseño de SPA. Puede usar un marco como AngularJS. No intente implementar un SPA sin usar buenos patrones de diseño porque puede terminar teniendo problemas.

Desventajas : Técnicamente, el diseño y el desarrollo inicial de SPA es complejo y puede evitarse. Otras razones para no usar este SPA pueden ser:

• a) Seguridad: la aplicación de página única es menos segura en comparación con las páginas tradicionales debido a las secuencias de comandos entre sitios (XSS).
• b) Pérdida de memoria: la pérdida de memoria en JavaScript puede incluso hacer que la computadora potente se desacelere. Como los sitios web tradicionales alientan a navegar entre las páginas, por lo tanto, cualquier pérdida de memoria causada por la página anterior casi se limpia dejando menos residuos.
• c) El cliente debe habilitar JavaScript para ejecutar SPA, pero en aplicaciones de varias páginas, JavaScript se puede evitar por completo.
• d) El SPA crece a un tamaño óptimo, lo que causa un largo tiempo de espera. Por ejemplo: trabajar en Gmail con una conexión más lenta.

Además de lo anterior, otras limitaciones arquitectónicas son la pérdida de datos de navegación, sin registro del historial de navegación en el navegador y la dificultad en las pruebas funcionales automatizadas con selenio.

Este enlace explica las ventajas y desventajas de la aplicación de página única.

En mi desarrollo encontré dos ventajas distintas para usar un SPA. Eso no quiere decir que no se pueda lograr lo siguiente en una aplicación web tradicional, solo que veo un beneficio incremental sin introducir desventajas adicionales.

• Posibilidad de una menor solicitud del servidor, ya que la representación de contenido nuevo no siempre es una solicitud del servidor http para una nueva página html. Pero digo potencial porque el nuevo contenido podría requerir fácilmente una llamada de Ajax para obtener datos, pero esos datos podrían ser incrementalmente más livianos que el marcado en sí mismo, lo que proporciona un beneficio neto.

• La capacidad de mantener el "Estado". En sus términos más simples, establezca una variable al ingresar a la aplicación y estará disponible para otros componentes a lo largo de la experiencia del usuario sin pasarla o establecerla en un patrón de almacenamiento local. Sin embargo, la administración inteligente de esta capacidad es clave para mantener el alcance de nivel superior despejado.

Además de requerir JS (que no es una locura requerir de aplicaciones web), en mi opinión, otras desventajas notables no son específicas de SPA o pueden mitigarse a través de buenos hábitos y patrones de desarrollo.

Intente no considerar el uso de un SPA sin definir primero cómo abordará la seguridad y la estabilidad de la API en el lado del servidor. Entonces verá algunas de las verdaderas ventajas de usar un SPA. Específicamente, si usa un servidor RESTful que implementa OAUTH 2.0 por seguridad, logrará dos separaciones fundamentales de preocupaciones que pueden reducir sus costos de desarrollo y mantenimiento.

1. Esto moverá la sesión (y su seguridad) al SPA y liberará a su servidor de toda esa sobrecarga.
2. Sus API se vuelven estables y fácilmente extensibles.

Insinuado anteriormente, pero no se hace explícito; Si su objetivo es implementar aplicaciones de Android y Apple, escribir un SPA de JavaScript envuelto por una llamada nativa para alojar la pantalla en un navegador (Android o Apple) elimina la necesidad de mantener una base de código de Apple y una base de código de Android.

Entiendo que esta es una pregunta anterior, pero me gustaría agregar otra desventaja de las aplicaciones de una sola página:

Si crea una API que devuelve resultados en un lenguaje de datos (como XML o JSON) en lugar de un lenguaje de formato (como HTML), está permitiendo una mayor interoperabilidad de aplicaciones, por ejemplo, en aplicaciones de empresa a empresa (B2B). Dicha interoperabilidad tiene grandes beneficios pero permite a las personas escribir software para "extraer" (o robar) sus datos. Esta desventaja particular es común a todas las API que usan un lenguaje de datos, y no a los SPA en general (de hecho, un SPA que le pide al servidor HTML preprocesado lo evita, pero a expensas de una separación de modelo / vista deficiente). Este riesgo expuesto por esta desventaja puede mitigarse por diversos medios, como la limitación de solicitudes y el bloqueo de conexiones, etc.