¿Qué tan seguras son las solicitudes ocultas de AJAX de ese falso rendimiento?

47

¿Qué es una solicitud AJAX oculta?

He notado un aumento en el uso de solicitudes ocultas de AJAX diseñadas para hacer que la acción de un usuario parezca ocurrir inmediatamente. Me referiré a este tipo de solicitud AJAX como no bloqueante. Es una solicitud de AJAX realizada sin que el usuario se dé cuenta de que está sucediendo, se realiza en segundo plano y su operación es silenciosa ( no hay información detallada para indicar una finalización exitosa de la llamada de AJAX ). El objetivo es hacer que la operación parezca que ha ocurrido inmediatamente cuando realmente no ha terminado.

Aquí hay ejemplos de solicitudes AJAX sin bloqueo;

  • El usuario hace clic en eliminar en una colección de correos electrónicos. Los elementos desaparecen inmediatamente de su bandeja de entrada y pueden continuar con otras operaciones. Mientras tanto, una solicitud AJAX está procesando la eliminación de los elementos en segundo plano.
  • El usuario completa un formulario para nuevos registros. Clics guardar. El nuevo elemento aparece en la lista inmediatamente. El usuario puede continuar agregando nuevos registros.

Para aclarar, aquí hay ejemplos de bloqueo de solicitudes AJAX;

  • El usuario hace clic en eliminar en una colección de correos electrónicos. Aparece un cursor de reloj de arena. Se realiza la solicitud AJAX y, cuando responde, el cursor del reloj de arena se apaga. El usuario tiene que esperar un segundo para que se complete la operación.
  • El usuario completa un formulario para nuevos registros. Clics guardar. El formulario se vuelve gris con una animación de cargador AJAX. Se muestra un mensaje "Sus datos se guardaron" y el nuevo registro aparece en la lista.

La diferencia entre los dos escenarios anteriores es que una configuración de AJAX sin bloqueo no proporciona información sobre el desempeño de una operación, y una configuración de AJAX de bloqueo sí.

El riesgo de solicitudes AJAX ocultas

El mayor riesgo de este estilo de solicitud AJAX es que la aplicación web podría estar en un estado completamente diferente cuando la solicitud AJAX falla.

Por ejemplo, un ejemplo sin bloqueo;

  • El usuario selecciona un montón de correos electrónicos. Haga clic en el botón Eliminar. La operación parece ocurrir inmediatamente (los elementos simplemente desaparecen de la lista). Luego, el usuario hace clic en el botón redactar y comienza a escribir un nuevo correo electrónico. Es en este momento que el código JavaScript descubre que la solicitud AJAX ha fallado. El script podría mostrar un mensaje de error, pero realmente no tiene sentido en este momento.

Alternativamente, un ejemplo de bloqueo;

  • El usuario selecciona un montón de correos electrónicos. Haga clic en el botón Eliminar. Ve un reloj de arena, pero la operación falla. Reciben un mensaje de error que dice "error. Bla bla bla". Se devuelven a la lista de correos electrónicos y aún tienen seleccionados los correos electrónicos que querían eliminar. Podrían intentar eliminarlos nuevamente.

También existen otros riesgos técnicos al realizar solicitudes AJAX sin bloqueo. El usuario podría cerrar el navegador, podría navegar a otro sitio web y podría navegar a otra ubicación en la web actual que haga que el contexto de cualquier respuesta de error no tenga sentido.

Entonces, ¿por qué se está volviendo tan popular?

Facebook, Google, Microsoft, etc., etc., todos estos grandes dominios utilizan cada vez más las solicitudes AJAX sin bloqueo para hacer que las operaciones aparezcan que se realicen de manera instantánea. También he visto un aumento en los editores de formularios que tienen ningún botón para guardar o enviar . Tan pronto como salga de un campo o presione enter. El valor se guarda. No hay ningún mensaje de tu perfil se ha actualizado o el paso de guardado.

Las solicitudes de AJAX no son una certeza, y no deberían ser tratadas como exitosas hasta que se hayan completado, pero muchas de las aplicaciones web más importantes están funcionando de esa manera.

¿Estos sitios web que utilizan llamadas AJAX no bloqueantes para simular aplicaciones receptivas corren un riesgo innecesario al costo de aparecer rápidamente?

¿Es este un patrón de diseño que todos deberíamos seguir para seguir siendo competitivos?

    
pregunta cgTag 31.01.2013 - 16:36

6 respuestas

62

No es tanto el rendimiento "falso" como la capacidad de respuesta real. Hay varias razones por las que es popular:

  • Las conexiones a internet son bastante confiables en la actualidad. El riesgo de que falle una solicitud AJAX es muy bajo.
  • Las operaciones que se realizan no son realmente críticas para la seguridad. Si sus correos electrónicos no se eliminan en el servidor, lo peor que puede pasar es que tenga que eliminarlos nuevamente la próxima vez que visite la página.
  • Puede diseñar su página para deshacer la acción si la solicitud falla, pero realmente no tiene que ser tan sutil porque significa que su conexión con el servidor está interrumpida. Es más fácil decir "Conexión perdida. No se pueden guardar los cambios recientes. Inténtelo de nuevo más tarde".
  • Puede diseñar su página para permitir solo una solicitud pendiente de AJAX, por lo que su estado no se desincronizará demasiado desde el servidor.
  • El navegador le advierte si intenta cerrar o navegar fuera de una página mientras está pendiente una solicitud AJAX.

    
respondido por el Karl Bielefeldt 31.01.2013 - 17:06
32

Asumir que algo funcionará y mostrar un error en caso de que falle en el lado remoto es mucho más fácil de usar que impedir que el usuario haga otra cosa hasta que haya una respuesta del servidor.

Un cliente de correo electrónico es en realidad un ejemplo excelente para esto: cuando tengo una lista con 5 correos electrónicos y el más alto está seleccionado, espero que al pulsar DEL tres veces Se eliminan los tres primeros correos electrónicos. Con "AJAX sin bloqueo", esto funciona bien: cada vez que presiono la tecla, el correo electrónico seleccionado se elimina de inmediato. Si algo sale mal, se muestra un error y se vuelven a mostrar los correos electrónicos que no se eliminaron correctamente O la página se vuelve a cargar para eliminar el estado local incoherente.

Entonces, en el caso más común , eso es el éxito, mejora la facilidad de uso. En el caso raro - error: la usabilidad está degradada (el elemento eliminado se muestra nuevamente o la aplicación se "reinicia") pero al crear una aplicación, por lo general, desea tener la mejor usabilidad para los casos comunes, no en caso de errores.

    
respondido por el ThiefMaster 31.01.2013 - 16:53
14

A los usuarios no les importa lo que hace su software detrás de escena: quieren que sus acciones tengan un impacto visible y que puedan trabajar a su ritmo.

Si una acción tuvo éxito en el lado del cliente, como eliminar correos electrónicos, es su trabajo hacer que también sea exitoso en el lado del servidor. ¿Por qué falló la eliminación? Si se debe a algún tipo de limitación (por ejemplo, no puede eliminar un correo electrónico que se haya archivado), se debe informar al usuario de que antes su acción falló.

Si el error se debe a algo más grave (digamos que se produce un bloqueo de la base de datos), debería tener una forma de guardar la operación y volver a intentarlo cuando el sistema vuelva a funcionar.

Un buen ejemplo de cómo manejar esto es la forma en que Facebook maneja el chat. No hay forma de evitar que un usuario se desconecte repentinamente, lo que significa que no podrá leer los mensajes que envió antes de que se fueran. En lugar de mostrar un error, el sistema guarda todos esos mensajes y los pone a disposición del usuario cuando regresa. No se pierden datos.

    
respondido por el DistantEcho 31.01.2013 - 17:15
5

Usted puede comprometerse entre las dos opciones. Por ejemplo, si el usuario elimina un correo electrónico, puede marcarlo de color rojo o gris hasta que obtenga una confirmación del servidor, y solo luego eliminarlo de la lista. El usuario aún puede hacer otras cosas mientras una acción está pendiente, por lo que no está bloqueando, pero aún le deja un pequeño recordatorio al usuario de que sus acciones aún no se han comprometido.

Amazon AWS adopta este enfoque: cuando detiene / inicia una instancia, la casilla de verificación que le permite seleccionarla se convierte en una rueda giratoria (por lo que no puede hacer nada durante unos segundos), pero esto no bloquearle de interactuar con otras instancias.

    
respondido por el valtron 01.02.2013 - 00:43
3

Creo que esto se une a más y más sitios web que intentan comportarse como Aplicaciones y hacen más procesamiento en el navegador (como validar datos de formularios) que los sitios más tradicionales. No veo mucho problema en eso, siempre y cuando su código sea confiable y usted pueda esperar que tenga éxito en condiciones normales.

Dice "Es en este momento que el código de JavaScript descubre que la solicitud de AJAX ha fallado. La secuencia de comandos podría mostrar un mensaje de error, pero realmente no tiene sentido en este momento".

¿Por qué debería ser inútil? Puede volver a la lista de correos electrónicos y hacer la eliminación nuevamente. ¿Por qué esperar en su lugar? En realidad, no hay mucho "riesgo" y no "parecen" ser rápidos, en realidad funcionan más rápido. Entonces, si la actividad no es "crítica", ¿por qué ser lento?

    
respondido por el thorsten müller 31.01.2013 - 16:45
1

Mi 2c es: hay situaciones en las que es mejor tener, como dice, operaciones Ajax "sin bloqueo" y otras en las que es una mala elección de diseño. Ejemplo: votando un video de YouTube. Realmente no quieres que se bloquee ninguna parte de la página mientras haces clic en los pequeños comienzos allí. Es mejor fallar en silencio. Incluso un mensaje de confirmación sería sobre-matar. Sin embargo, su ejemplo con eliminación de correo electrónico calificaría como obligatorio para la solicitud Ajax de tipo de bloqueo.

Mongo DB hace algo así (y esto podría considerarse como un ejemplo de aplicación de escritorio). Tienen varias "Preocupaciones de escritura" para sus operaciones, y puede configurarlo a diferentes valores para cada operación, que van desde el "retorno inmediato y no espere nada" al "bloque" hasta que tenga una confirmación de transferencia de red exitosa y luego vuelva a "esperar" hasta que el contenido esté programado correctamente para la escritura en disco en la máquina remota antes de su devolución ". Obviamente, si crea un cliente pesado de escritorio (como en C ++) utilizando el controlador Mongo, establecerá la preocupación de escritura más ligera para las operaciones de db con una "criticidad" mínima (como la comprobación de un nuevo correo electrónico), y otros en las preocupaciones de escritura más estrictas .

Aunque veo la utilidad de no bloquear el Ajax, estoy de acuerdo contigo en que está sucediendo demasiado. En un punto hubo al menos un famoso sitio de "redes sociales" que haría esto para subir fotos. Elegiste tu foto para subir y luego bam, enseguida te diría que está lista, y luego, al día siguiente, cuando quisieras agregar algunas fotos más (o usarlas que creías que ya habías agregado), nunca fue encontrado. Más tarde, se dieron por vencidos y se tomaron el tiempo para esperar la respuesta (y de hecho, a veces recibiría mensajes como "no se pudo cargar la foto, inténtelo más tarde").

    
respondido por el Shivan Dragon 31.01.2013 - 17:53

Lea otras preguntas en las etiquetas