¿Qué tan seguras son las solicitudes ocultas de AJAX que tienen un rendimiento falso?

¿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 suceder de inmediato. Me referiré a este tipo de solicitud AJAX como sin bloqueo. Es una solicitud AJAX hecha sin que el usuario sepa que está sucediendo, se realiza en segundo plano y su operación es silenciosa ( no hay detalles para indicar una finalización exitosa de la llamada AJAX ). El objetivo es hacer que la operación parezca que ha sucedido 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 de inmediato. El usuario puede continuar agregando nuevos registros.

Para aclarar, aquí hay ejemplos de bloqueo de solicitud 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 "Se guardaron sus datos", 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 retroalimentación de un rendimiento operativo, y una configuración de AJAX de bloqueo sí.

El riesgo de solicitudes ocultas de AJAX

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

Por ejemplo, un ejemplo sin bloqueo;

• El usuario selecciona un montón de correos electrónicos. Hace clic en el botón Eliminar. La operación parece ocurrir de inmediato (los elementos simplemente desaparecen de la lista). Luego, el usuario hace clic en el botón de redacción y comienza a escribir un nuevo correo electrónico. Es en este momento que el código JavaScript descubre que la solicitud AJAX falló. 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. Hace 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". Vuelven a la lista de correos electrónicos y todavía tienen seleccionados los correos que querían eliminar. Podrían intentar eliminarlos nuevamente.

También existen otros riesgos técnicos para realizar solicitudes AJAX sin bloqueo. El usuario puede cerrar el navegador, puede navegar a otro sitio web y puede navegar a otra ubicación en la web actual que hace 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 dominios grandes utilizan cada vez más solicitudes AJAX sin bloqueo para hacer que las operaciones parezcan que se realizan al instante. También he visto un aumento en los editores de formularios que no tienen botón de guardar o enviar . Tan pronto como salga de un campo o presione enter. El valor se guarda. No hay ningún mensaje de perfil actualizado o paso de guardado.

Las solicitudes de AJAX no son una certeza, y no deben tratarse como exitosas hasta que se hayan completado, pero muchas de las principales aplicaciones web están funcionando así.

¿Estos sitios web que usan llamadas AJAX sin bloqueo para simular aplicaciones receptivas corren un riesgo innecesario a costa de aparecer rápidamente?

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

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 hoy en día. 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 sucede es que debe 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 al servidor está interrumpida. Es más fácil decir "Conexión perdida. No se pueden guardar los cambios recientes. Inténtalo de nuevo más tarde".
• Puede diseñar su página para permitir solo una solicitud AJAX pendiente, para que su estado no se desincronice demasiado del servidor.
• El navegador le advierte si intenta cerrar o navegar fuera de una página mientras hay una solicitud AJAX pendiente.

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 bloquear al usuario para que no haga nada más hasta que haya una respuesta del servidor.

Un cliente de correo electrónico es en realidad un gran ejemplo para esto: cuando tengo una lista con 5 correos electrónicos y se selecciona el superior, espero que al presionar DELtres veces se eliminen los primeros tres 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 los correos electrónicos no eliminados correctamente se muestran nuevamente O la página se vuelve a cargar para eliminar el estado local inconsistente.

Entonces, en el caso más común , que es el éxito, mejora la usabilidad. En el caso poco frecuente (falla), la usabilidad se degrada (el elemento eliminado vuelve a aparecer o la aplicación se "reinicia"), pero al crear una aplicación, generalmente desea tener la mejor usabilidad para casos comunes, no en caso de errores.

Los usuarios no se preocupan por lo que su software está haciendo detrás de escena: quieren que sus acciones tengan un impacto visible y que puedan trabajar a su ritmo.

Si una acción fue exitosa en el lado del cliente, como eliminar correos electrónicos, es su trabajo hacerla exitosa también 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 ha archivado), se debe informar al usuario antes de que su acción falle.

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

Un buen ejemplo de cómo administrar 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 irse. En lugar de mostrar un error, el sistema guarda todos esos mensajes y los pone a disposición del usuario cuando regrese. No se pierden datos.

Puede comprometerse entre las dos opciones. Por ejemplo, si el usuario elimina un correo electrónico, puede marcarlo en rojo o gris hasta que reciba 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 deja un pequeño recordatorio para el 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 ruleta (por lo que no puede hacer nada durante unos segundos), pero esto no le impide interactuando con otras instancias.

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 los datos del formulario) que los sitios más tradicionales. No veo demasiado problema en eso, siempre y cuando su código sea confiable y pueda esperar que tenga éxito en condiciones normales.

Usted dice "Es en este momento que el código JavaScript descubre que la solicitud AJAX falló. El script podría mostrar un mensaje de error, pero en este momento no tiene sentido".

¿Por qué debería ser inútil? Puede volver a la lista de correos electrónicos y volver a eliminar. ¿Por qué esperar en su lugar? En realidad, no existe un gran "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 lenta?

Mi 2c es: hay situaciones en las que es mejor tener, como usted dice, operaciones de Ajax "sin bloqueo" y otras en las que es una mala elección de diseño. Ejemplo: votar un video de YouTube. Realmente no desea que se bloquee ninguna parte de la página mientras hace clic en los pequeños comienzos allí. Es mejor fallar en silencio. Incluso un mensaje de confirmación sería exagerado. Sin embargo, su ejemplo con la eliminación de correo electrónico calificaría como obligatorio para la solicitud de 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 con diferentes valores para cada operación, que van desde "regresar de inmediato y no esperar nada" hasta "bloquear" hasta que haya confirmado la transferencia exitosa de la red y luego regrese "a" espere hasta que el contenido esté correctamente programado para escritura en disco en la máquina remota antes de su devolución ". Obviamente, si crea un cliente grueso de escritorio (como C ++) con el controlador Mongo, establecería la preocupación de escritura más ligera para las operaciones de db de "criticidad" mínima (como verificar si hay correo electrónico nuevo) y otras cuestiones de escritura más estrictas .

Si bien veo la utilidad de Ajax sin bloqueo, estoy de acuerdo con usted en que está sucediendo demasiado. En un momento había al menos un sitio famoso de "redes sociales" que haría esto para subir fotos. Elegiste tu foto para subir y luego bam, de inmediato te diría que está hecha, y luego, al día siguiente, cuando quisiste agregar algunas fotos más (o usar en las que creías que ya habías agregado), nunca fue encontrado. Más tarde se dieron por vencidos con esto, y en realidad se tomaron el tiempo de esperar la respuesta (y de hecho a veces recibía mensajes como "no se pudo cargar la foto, intente más tarde").