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

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.

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.

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.

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.

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?

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").