procesamiento paralelo frente a procesamiento del lado del cliente + ajax?

Question

buscando algunos consejos generales y/o pensamientos ...

Estoy creando lo que creo que es más una aplicación web que una página web, porque pretendo que sea como una aplicación de Gmail donde se iría la página se abre durante todo el día mientras se "empujan" las actualizaciones a la página (para el interesado estoy usando la técnica de programación del cometa). Nunca antes había creado una página web tan rica en ajax y javascript (ahora soy un gran admirador de jquery). debido a esto, una y otra vez cuando estoy implementando una nueva característica que requiere un cambio dinámico en la UI que el servidor necesita saber, me enfrento con la misma pregunta:

1) ¿debería hacer todo el procesamiento en el cliente en javascript y publicar lo menos posible a través de ajax o 2) debo publicar una solicitud al servidor a través de ajax, hacer que el servidor haga todo el procesamiento y luego devolver el nuevo html. luego, en la respuesta ajax, realizo una tarea sencilla con el nuevo HTML

. Siempre me he sentido inclinado a seguir el # 1. esta aplicación web, imagino, puede ser muy hablador con todas las solicitudes de Ajax. Mi idea es minimizar al máximo el tamaño de las solicitudes y las respuestas, y confiar en que los motores de JavaScript mejoran continuamente para hacer la mayor cantidad posible de actualizaciones de UI y de procesamiento. He descubierto con jquery que puedo hacer tanto en el lado del cliente que no podría haberlo hecho antes. mi código de JavaScript es en realidad mucho más grande y más complejo que mi código de servidor. también hay calculcaciones simples que debo realizar y también las he impulsado en el lado del cliente.

Supongo que la principal pregunta que tengo es, ¿SIEMPRE debemos esforzarnos por el procesamiento del lado del cliente sobre el procesamiento del lado del servidor siempre que sea posible? Siempre he sentido que, cuanto menos tenga que manejar el servidor, mejor será para la escalabilidad/el rendimiento. deje que el poder del procesador del cliente haga todo el trabajo (si es posible).

thoughts?

Answer 1

Por supuesto depende de los datos, pero la mayoría de las veces si puede empujarlo hacia el lado del cliente, sí. Haga que el cliente haga más del procesamiento y use menos ancho de banda. (De nuevo, esto depende de los datos, puede acceder a los casos en los que debe enviar más datos para hacerlo desde el lado del cliente).

Answer 2

Estoy de acuerdo contigo. Empuje tanto como sea posible a los usuarios, pero no demasiado. Si tu aplicación se ralentiza o, incluso peor, bloquea su navegador, pierdes.

Mi consejo es que realmente pruebe cómo su aplicación actúa cuando se enciende durante todo el día. Verifique que no haya pérdidas de memoria. Compruebe que no haya una solicitud ajax creada cada medio segundo después de trabajar con la aplicación durante un tiempo (los temporizadores en JS pueden ser problemáticos en algún momento).

Aparte de eso, nunca se realiza la validación de entrada de usuario con javascript. Siempre duplicarlo en el servidor.

Editar

usar jQuery live binding. Le ahorrará mucho tiempo al volver a vincular el contenido generado y hará que su arquitectura sea más clara. Lamentablemente, cuando estaba desarrollando con jQuery todavía no estaba disponible; usamos otras herramientas con el mismo efecto.

En el pasado también tuve un problema cuando la generación de una parte de página que usa ajax depende de la generación de otra parte. Generar primera parte primera y segunda parte segunda hará que su página sea más lenta de lo esperado. Planea esto en frente. Desarrolle páginas para que ya tengan todo el contenido cuando se abran.

También (también en páginas simples), mantenga baja la cantidad de archivos a los que se hace referencia en un servidor. Únase a las bibliotecas de JavaScript y css en un archivo en el lado del servidor. Mantenga las imágenes en un host separado, mejores hosts separados (crear solo un dominio de tercer nivel también lo hará). Aunque esto solo vale la pena en producción; hará que el proceso de desarrollo sea más difícil.

Answer 3

Algunas cosas, como las comprobaciones de seguridad, siempre deben realizarse en el servidor. Si tiene un cálculo que requiere una gran cantidad de datos y produce menos datos, también colóquelo en el servidor.

Por cierto, ¿sabía que podía ejecutar Javascript en el lado del servidor, renderizando plantillas y accediendo a las bases de datos? Echa un vistazo al ecosistema CommonJS.

Answer 4

También podría haber problemas de compatibilidad entre navegadores. Si está utilizando una biblioteca de navegador cruzado, del lado del cliente (por ejemplo, JQuery) y puede manejar todo el procesamiento que necesita, puede dejar que la biblioteca se ocupe de ello. Generar un servidor HTML cruzado en el servidor puede ser más difícil (tiende a ser más manual), dependiendo de la complejidad del marcado.

Answer 5

Existen varias consideraciones a la hora de decidir si los nuevos fragmentos de HTML creados por una solicitud de Ajax deben construirse en el lado del servidor o del cliente. Algunas cosas a considerar:

• Rendimiento. El trabajo que su servidor debe hacer es lo que le debe preocupar. Al hacer más del procesamiento en el lado del cliente, reduce la cantidad de trabajo que hace el servidor y acelera las cosas. Si el servidor puede enviar un poco de JSON en lugar de un fragmento HTML gigante, por ejemplo, sería mucho más eficiente dejar que el cliente lo haga. En situaciones donde se envía una pequeña cantidad de datos de cualquier manera, la diferencia es probablemente insignificante.

• Legibilidad. La desventaja de generar marcado en su JavaScript es que es mucho más difícil de leer y mantener el código. Incrustar HTML en cadenas entrecomilladas es desagradable de mirar en un editor de texto con coloreado de sintaxis establecido en JavaScript y hace que la edición sea más difícil.

• Separación de datos, presentación y comportamiento. En la línea de la legibilidad, tener fragmentos de HTML en tu JavaScript no tiene mucho sentido para la organización del código. Las plantillas HTML deben manejar el marcado y JavaScript debe dejarse solo para controlar el comportamiento de su aplicación. El contenido de un fragmento HTML que se inserta en una página no es relevante para su código JavaScript, solo el hecho de que se está insertando, dónde y cuándo.

que tienden a inclinarse más hacia la restitución fragmentos HTML desde el servidor cuando se trata de respuestas ajax, por las razones de legibilidad y la organización del código que menciono arriba. Por supuesto, todo depende de cómo funciona tu aplicación, de la intensidad del procesamiento de las respuestas de Ajax y del tráfico que recibe la aplicación. Si el servidor tiene que hacer un trabajo importante para generar estas respuestas y está causando un cuello de botella, entonces puede ser más importante enviar el trabajo al cliente y renunciar a otras consideraciones.

Answer 6

Actualmente estoy trabajando en una aplicación bastante computacionalmente pesada y estoy renderizando casi todo en el lado del cliente. No sé exactamente qué hará su aplicación (más detalles serían geniales), pero diría que su aplicación probablemente haga lo mismo. Solo asegúrese de que todos los códigos relacionados con la seguridad y la base de datos se encuentren en el lado del servidor, ya que al no hacerlo se abrirán agujeros de seguridad en su aplicación.Aquí hay algunas pautas generales que debo seguir:

• No confíe nunca en que el usuario tenga un navegador o una computadora súper rápida. Algunas personas están usando Internet Explore 7 en máquinas antiguas, y si es demasiado lento para ellas, perderán muchos clientes potenciales. Pruebe en tantos buscadores y máquinas como sea posible.
• Cada vez que tenga algún código que podría retrasar o congelar el navegador momentáneamente, muestra un mecanismo de retroalimentación (en la mayoría de los casos, un simple mensaje de "Carga" lo hará) para decirle al usuario que algo realmente está sucediendo, y el navegador no se congeló al azar.
• intente cargue todo lo que pueda durante la inicialización y caché todo. En mi aplicación, estoy haciendo algo similar a Gmail: mostrar una barra de carga, cargar todo lo que la aplicación alguna vez necesitará, y luego darle al usuario una experiencia fluida de allí en adelante. Sí, tendrán que esperar potencialmente unos segundos para que se cargue, pero después de eso no debería haber problemas.
• Minimiza la manipulación del DOM. El rendimiento de JavaScript crunch de números sin procesar puede ser "lo suficientemente rápido", pero el acceso al DOM sigue siendo lento. Evita crear y destruir elementos; en su lugar, simplemente escóndelos si no los necesitas en este momento.

Answer 7

Recientemente me encontré con el mismo problema y decidí ir con el procesamiento del lado del navegador, todo funcionó muy bien en FF e IE8 e IE8 en modo 7, pero luego ... nuestro cliente, utilizando Internet Explorer 7 tuvo problemas , la aplicación se congelaría y aparecería un cuadro de tiempo de espera de script, había invertido demasiado trabajo en la solución para descartarlo, así que terminé pasando una hora más o menos optimizando el script y agregando setTimeout siempre que sea posible.

¿Mis sugerencias?

• Si es posible, mantenga los cálculos no críticos del lado del cliente.
• Para mantener bajas las transferencias de datos, use JSON y deje que el lado del cliente resuelva el HTML.
• Pruebe su script usando el mínimo común denominador.
• Si es necesario, use la función de creación de perfiles en FireBug. Corolario: utilice la versión no comprimida (desarrollo) de jQuery.

Answer 8

esto es posible, pero con la carga de la página intial pesada & & un uso intensivo de la memoria caché. tomar gmail como ejemplo

• En la carga de la página inicial, descarga la mayoría de los archivos js que necesitaba para ejecutar. Y sobre todo en caché.
• no sobre el uso de imágenes y gráficos.
• Cargue todos los datos que se deben mostrar en la carga inicial y junto con los datos de usuario predecibles subsiguientes. en gmail & último correo yahoo, la bandeja de entrada no está poblada únicamente con el cuerpo de conversación de correo único, carga los primeros mensajes de correo electrónico completos por adelantado en el momento de la carga de la página. el secreto de la alta resolución viene con el costo (gmail pide que se cargue la versión ligera si el ancho de banda es bajo. Creo que la mayoría de nosotros lo hemos experimentado).
• siga KISS principio. significa mantener tu diseño simple.
• Y nunca intente renderizar toda la página utilizando javascript, en cualquier caso, no puede predecir a todos sus usuarios usando los sistemas de configuración alta o sistemas de ancho de banda alto.

Es inteligente dividir la carga de trabajo entre su servidor y su cliente.

Answer 9

Si cree que en el futuro podría querer crear una API para su aplicación (comunicándose con iPhone o aplicaciones de Android, permitiendo que otros sitios se integren con la suya), tendría que duplicar un código para todos esos dispositivos si vas con una implementación de servidor básica de tu aplicación.