it-swarm-es.com

Ventajas / desventajas de las aplicaciones web "separadas"

Estoy en el proceso de diseñar una aplicación web PHP/MySQL (próximamente a ser) bastante grande. He llegado a una bifurcación en el camino en cuanto a arquitectura interna; Puedo construir el sitio web como una aplicación web "tradicional" donde, cuando haces una solicitud, el servidor te construye una página HTML, te envía toda la página y el navegador la procesa, o puedo construirla como "separada" "aplicación web donde se proporciona toda la estructura HTML y el código de la aplicación al navegador después de la carga inicial, y la aplicación utiliza devoluciones de llamada de JavaScript para obtener datos específicos o emitir comandos a través de una API unificada. Además, tengo la intención de que haya múltiples versiones del sitio (computadora de escritorio, móvil, iPhone/Android, compatible con motores de búsqueda, etc.) y en algún momento, tal vez incluso aplicaciones móviles o de escritorio independientes.

¿Qué ventajas/desventajas tienen ustedes, como desarrolladores web, con cada una de estas arquitecturas? ¿Hay una razón clara por la que debería ir con uno sobre el otro? ¿Es más una cosa de preferencia de los desarrolladores?

3
Adam Maras

En primer lugar, si va con un sitio web asincrónico pesado o no, no tendrá mucho efecto en su capacidad para crear aplicaciones de escritorio/iPhone y móviles porque no tiene nada que ver con ellas. De cualquier manera, no podrá reutilizar su código.

Además, los sitios asincrónicos pueden ser tan lentos o más lentos que los sitios normales. Por lo general, ese tipo de funcionalidad se agrega por una razón, específicamente para una experiencia de usuario enriquecida. El uso de JavaScript tiende a perjudicarlo en SEO porque los webcrawlers no pueden comprender completamente la intención del JavaScript y, por lo tanto, lo ignoran en su mayoría.

Creo que lo que está buscando es una forma de reducir la sobrecarga de desarrollo escribiendo solo su nivel funcional (medio) una vez y utilizando el mismo para todas sus aplicaciones. En este caso, creo que hay valor, pero, francamente, este tipo de arquitecturas son más difíciles de configurar y requieren mucho tiempo. Creo que debería desarrollar su sitio web lo mejor que pueda y mantener su código de nivel medio tan fuerte como sea posible. De esa manera, cuando llegue el momento de agregar una aplicación para iPhone o lo que sea, podrá pasar a un modelo con un nivel medio común más fácilmente

Lo que realmente estoy defendiendo aquí es dar pequeños pasos. No intentes escribir código ahora para manejar cosas que aún no sabes. Simplemente escriba el código que necesita y hágalo lo más flexible posible.

4
Ben Hoffman

Creo que la idea de una aplicación "separada" que dependa en gran medida de JavaScript/AJAX te va a meter en muchos problemas. Algunas cosas fuera de mi cabeza:

  1. Va a ser malo para el SEO ya que Google tendrá dificultades para indexar cualquier cosa.
  2. Va a ser difícil hacerlo "favorito"
  3. Tendrá dificultades con los dispositivos móviles, ya que muchos de ellos tienen un soporte de JavaScript muy limitado (o roto).
5
Eric Petroelje

Primero, no se ofenda si esta respuesta es demasiado obvia o básica. Su uso de "separados" en lugar de términos como Ajax o jQuery me hace asumir menos experiencia con este tema. Por supuesto, podría estar malinterpretando la pregunta, así que mis disculpas si ese es el caso.

Usa ambos, pero sabiamente

Piense en su elección de tareas del lado del servidor o del lado del cliente en términos de dónde y cómo se realiza una tarea de manera más eficiente. Esto lo ayudará a procesar las páginas rápidamente (en el servidor), pero descargará el trabajo al navegador donde tenga sentido hacerlo. Y, habrá áreas grises en las que solo tendrá que hacer un juicio. Tu trabajo es encontrar una división inteligente del trabajo.

¿Qué pertenece al lado del servidor?

(Este es un ejemplo extremo para ilustrar el punto). Digamos que está escribiendo una aplicación web que realiza algún tipo de búsqueda. No escribe Javascript del lado del navegador para llamar a un servicio web PHP del lado del servidor para recuperar una base de datos completa de 2GB para "liberar su servidor" y descargar la búsqueda en la máquina del usuario. Lo que debe hacer es obtener los términos de búsqueda del usuario con un formulario, POST de nuevo al servidor para consultar la base de datos directamente, y luego enviar los resultados del servidor al navegador.

La lógica aquí es que la base de datos en sí misma sabe cómo hacer mejor la consulta, el servidor está más cerca de los datos de origen y hay que mover menos datos entre los componentes. El navegador solo necesita lo que muestra, así que no lo envíe todo al navegador. (Sin mencionar el rendimiento relativo del lenguaje).

¿Qué pertenece al navegador?

El código del lado del navegador es su escenario "separado" (si lo entiendo correctamente). Pero para que el navegador haga casi cualquier cosa inteligente, debe contar con la cooperación del servidor.

Está bien, tienes tu aplicación de búsqueda funcionando pero quieres arreglarla con unos pantalones elegantes Ajax. Escriba un servicio web PHP para tomar algunas letras y devolver términos de búsqueda coincidentes, a la la función de "búsqueda sugerida" de Bing , Google, etc. Escriba el código de su navegador para sugerir solo términos después de que el usuario haya escrito tres o cuatro letras, por lo que su lista de sugerencias es pequeña. De vuelta en el servidor, indexe su base de datos en ese campo para que la búsqueda sea rápida, rápida, rápida.

Aquí el pensamiento es que "buscar sugerir" es una característica que debe dividirse entre el servidor y el cliente. El navegador puede manejar rápidamente montones de datos específicos y pequeños. El servidor puede obtener esa pila de datos específica y pequeña y dársela al cliente. Una división pobre sería que el servidor renderice una lista de monstruos (por ejemplo, 500,000 artículos) de posibles valores de campo como una isla XML incrustada en la página HTML, luego haga que el navegador busque eso a medida que el usuario escribe. (a) enviar todos esos datos al navegador es lento, (b) buscarlos en Javascript nunca será tan rápido como dejar que el DB lo busque, y (c) es probable que explote la máquina de un usuario al introducir todos esos datos en el espacio de la aplicación de su navegador. Por otro lado, debe asegurarse seguro de que la llamada Ajax al servidor, y la consulta y el retorno posteriores son súper rápidos. No hay tonterías.

¿Dónde está el área gris?

Aquí de nuevo es una decisión judicial. Arriba, hablé sobre el servidor haciendo la búsqueda, luego enviando los resultados al navegador. Pero, surge la pregunta, ¿permite que el navegador envíe los términos de búsqueda con el formulario y haga que el servidor presente la página de resultados, o utiliza Ajax/Javascript del lado del cliente para enviar los términos de búsqueda y recuperar los resultados, luego renderizarlos en un DIV para evitar una actualización de la página? Ambos son validos. En cuanto a los recursos, no hay un beneficio real de ninguna manera. La forma Ajax puede proporcionar una mejor experiencia de usuario pero, dependiendo de su aplicación y las circunstancias, puede presentar algunos otros desafíos (por ejemplo, seguridad).

Línea de fondo

Use ambos apropiadamente. No escatime en pensar y aprender sobre el desempeño arquitectónico y la eficiencia. Mueva menos datos, menos veces. Eliminará la carga de sus servidores, sus bases de datos y los navegadores de sus usuarios.

2
b w

Para poder reutilizar el código, siempre puede mirar XSLT para la generación de páginas de destino y luego tener interfaces XML/JSON para AJAX (utilizando la interfaz XML para las páginas de destino XSLT).

Normalmente permitiría que el contenido y la interacción funcionen en una interfaz RESTful con un prefijo/json/... y/xml/... y aloje su contenido principal, convertido en marcado a través de XSLT en/...

De esta manera, las personas pueden aterrizar en cualquier página y de repente tener el sitio web AJAX completo. Las arañas pueden rastrear su sitio y usted se ha concentrado en el contenido/interfaces en primer lugar, parece una ganancia/ganancia.

Los sitios web móviles a veces necesitan diferentes diseños (¿sitios personalizados solo para iPhone?), Una simple conversión XSLT aquí o allá para diferentes usuarios puede reutilizar todo lo que ha hecho hasta ahora.

Recuerde diseñar para una salida HTML simple y navegación, las simplificaciones AJAX pueden seguir.

PS - Haz las transformaciones XSLT del lado del servidor

1
Metalshark