Dans quelle mesure sont cachés AJAX demande de fausses performances?
Qu'est-ce qu'une demande cachée AJAX?
J'ai remarqué une augmentation de l'utilisation des demandes cachées AJAX conçues pour que l'action d'un utilisateur semble se produire immédiatement. Je ferai référence à ce type de AJAX = demande non bloquante. Il s'agit d'une demande AJAX effectuée sans que l'utilisateur sache que cela se produit, elle est effectuée en arrière-plan et son fonctionnement est silencieux (il n'y a pas de mot pour indiquer une réussite de l'appel AJAX). Le but est de faire apparaître que l'opération a eu lieu immédiatement alors qu'elle n'est vraiment pas terminée.
Voici des exemples de non-blocage AJAX;
- L'utilisateur clique sur supprimer sur une collection d'e-mails. Les éléments disparaissent immédiatement de leur boîte de réception et ils peuvent poursuivre d'autres opérations. Pendant ce temps, une requête AJAX traite la suppression des éléments en arrière-plan.
- L'utilisateur remplit un formulaire pour les nouveaux enregistrements. Cliquez sur Enregistrer. Le nouvel élément apparaît immédiatement dans la liste. L'utilisateur peut continuer d'ajouter de nouveaux enregistrements.
Pour clarifier, voici des exemples de blocage AJAX request;
- L'utilisateur clique sur supprimer sur une collection d'e-mails. Un curseur sablier apparaît. La demande AJAX est effectuée et lorsqu'elle répond, le curseur du sablier est désactivé. L'utilisateur doit attendre une seconde pour que l'opération se termine.
- L'utilisateur remplit un formulaire pour les nouveaux enregistrements. Cliquez sur Enregistrer. Le formulaire devient gris avec un chargeur AJAX animé. Un message s'affiche "Vos données ont été enregistrées" et le nouvel enregistrement apparaît dans la liste.
La différence entre les deux scénarios ci-dessus est qu'une configuration non bloquante AJAX ne fournit pas de retour d'informations sur un fonctionnement opérationnel, et une configuration bloquante AJAX le fait.
Le risque de caché AJAX Requests
Le plus grand risque de ce style de demande AJAX est que l'application Web pourrait être dans un état complètement différent lorsque la demande AJAX échoue).
Par exemple, un exemple non bloquant;
- L'utilisateur sélectionne un tas d'e-mails. Clique sur le bouton Supprimer. L'opération semble se produire immédiatement (les éléments disparaissent simplement de la liste). L'utilisateur clique ensuite sur le bouton de composition et commence à taper un nouvel e-mail. C'est à ce moment que le code JavaScript découvre la requête AJAX a échoué. Le script pourrait afficher un message d'erreur, mais il est vraiment inutile pour le moment.
Alternativement, un exemple de blocage;
- L'utilisateur sélectionne un tas d'e-mails. Clique sur le bouton Supprimer. Voit un sablier, mais l'opération échoue. Ils reçoivent un message d'erreur disant "erreur. Bla bla bla". Ils sont retournés à la liste des e-mails et ils ont toujours les e-mails qu'ils voulaient supprimer sélectionnés. Ils pourraient tenter de les supprimer à nouveau.
Il existe également d'autres risques techniques pour l'exécution de requêtes non bloquantes AJAX. L'utilisateur pourrait fermer le navigateur, naviguer vers un autre site Web et naviguer vers un autre emplacement du site Web actuel qui rend le contexte de toute réponse d'erreur dénuée de sens.
Alors pourquoi devient-il si populaire?
Facebook, Google, Microsoft, etc. etc. tous ces grands domaines utilisent de plus en plus non-bloquant AJAX requêtes pour effectuer des opérations apparaissent qu'elles soient effectuées instantanément. J'ai également vu une augmentation des éditeurs de formulaires qui ont pas de bouton d'enregistrement ou d'envoi. Dès que vous quittez un champ ou appuyez sur Entrée. La valeur est enregistrée. Il n'y a pas votre profil a été mis à jour message ou étape d'enregistrement.
Les demandes AJAX ne sont pas une certitude et ne devraient pas être traitées comme réussies tant qu'elles ne sont pas terminées, mais de nombreuses applications Web majeures fonctionnent exactement comme ça.
Ces sites Web qui utilisent des appels non bloquants AJAX pour simuler des applications réactives prennent-ils un risque inutile au prix d'une apparition rapide?
Est-ce un modèle de conception que nous devrions tous suivre pour rester compétitifs?
Ce n'est pas tant une "fausse" performance qu'une réelle réactivité. Il y a plusieurs raisons pour lesquelles il est populaire:
- Les connexions Internet sont assez fiables de nos jours. Le risque d'échec d'une demande AJAX est très faible.
- Les opérations effectuées ne sont pas vraiment critiques pour la sécurité. Si vos e-mails ne sont pas supprimés sur le serveur, le pire qui se passe est que vous devez les supprimer à nouveau la prochaine fois que vous accédez à la page.
- Vous pouvez concevoir votre page pour annuler l'action si la demande échoue, mais vous n'avez pas vraiment besoin d'être aussi subtil car cela signifie que votre connexion au serveur est rompue. Il est plus facile de dire "Connexion perdue. Impossible d'enregistrer les modifications récentes. Réessayez plus tard."
- Vous pouvez concevoir votre page pour n'autoriser qu'une seule demande AJAX en attente, afin que votre état ne soit pas trop désynchronisé du serveur.
- Le navigateur vous avertit si vous essayez de fermer ou de quitter une page alors qu'une demande AJAX est en attente.
Supposer que quelque chose fonctionnera et afficher une erreur en cas d'échec du côté distant est beaucoup plus convivial que d'empêcher l'utilisateur de faire autre chose jusqu'à ce qu'il y ait une réponse du serveur.
Un client de messagerie est en fait un exemple excellent pour cela: lorsque j'ai une liste avec 5 e-mails et que le premier est sélectionné, je m'attends à ce que lorsque vous frappez DEL trois fois les trois premiers e-mails sont supprimés. Avec "AJAX non bloquant", cela fonctionne très bien - chaque fois que j'appuie sur la touche, l'e-mail sélectionné est immédiatement supprimé. Si quelque chose ne va pas, une erreur s'affiche et les e-mails qui ne sont pas correctement supprimés s'affichent à nouveau OR la page est rechargée pour se débarrasser de l'état local incohérent.
Donc, dans le cas le plus courant - c'est le succès - cela améliore la convivialité. Dans le cas rare - échec - l'utilisabilité est dégradée (l'élément supprimé réapparaît ou l'application est "redémarrée") mais lors de la création d'une application, vous voulez généralement avoir la meilleure utilisabilité pour les cas courants, pas en cas d'erreurs.
Les utilisateurs ne se soucient pas de ce que fait votre logiciel dans les coulisses: ils veulent que leurs actions aient un impact visible et puissent travailler à leur rythme.
Si une action a réussi du côté client - comme la suppression des e-mails - il est de votre devoir de la réussir également côté serveur. Pourquoi la suppression a-t-elle échoué? Si cela est dû à une sorte de limitation (par exemple, vous ne pouvez pas supprimer un e-mail qui a été archivé), l'utilisateur doit en être informé avant son action a échoué.
Si l'erreur est causée par quelque chose de plus grave (disons un plantage de la base de données), vous devriez avoir un moyen de sauvegarder l'opération et de la réessayer lorsque le système est à nouveau opérationnel.
Un bon exemple de gestion est la façon dont Facebook gère le chat. Il n'y a aucun moyen d'empêcher un utilisateur de se déconnecter soudainement, ce qui signifie qu'il ne pourra pas lire les messages que vous avez envoyés avant son départ. Au lieu d'afficher une erreur, le système enregistre tous ces messages et les met à la disposition de l'utilisateur à son retour. Aucune donnée n'est perdue.
Vous pouvez faire un compromis entre les deux options. Par exemple, si l'utilisateur supprime un e-mail, vous pouvez le marquer en rouge ou en gris jusqu'à ce que vous obteniez une confirmation de retour du serveur, puis le supprimer de la liste. L'utilisateur peut toujours faire d'autres choses pendant qu'une action est en attente, donc ce n'est pas un blocage, mais cela laisse un petit rappel à l'utilisateur que ses actions n'ont pas encore été validées.
Amazon AWS adopte cette approche: lorsque vous arrêtez/démarrez une instance, la case à cocher qui vous permet de la sélectionner se transforme en spinner (vous ne pouvez donc rien y faire pendant quelques secondes), mais cela ne vous empêche pas de interagir avec d'autres instances.
Je pense que cela s'accompagne de plus en plus de sites Web qui essaient de se comporter comme des applications et effectuent plus de traitements dans le navigateur (comme la validation des données de formulaire) que les sites plus traditionnels. Je ne vois pas trop de problème dans la mesure où votre code est fiable et que vous pouvez vous attendre à ce qu'il réussisse dans des conditions normales.
Vous dites "C'est à ce moment que le code JavaScript découvre la AJAX a échoué. Le script pourrait afficher un message d'erreur, mais il est vraiment inutile pour le moment."
Pourquoi cela devrait-il être inutile? Vous pouvez revenir dans la liste des e-mails et recommencer la suppression. Pourquoi attendre à la place? Il n'y a en fait pas beaucoup de "risque" et ils ne semblent pas "rapides", ils fonctionnent en fait plus vite. Alors si l'activité n'est pas "critique" pourquoi être lente?
Mon 2c est: il y a des situations où il vaut mieux avoir, comme vous le dites, des opérations Ajax "non bloquantes" et d'autres où c'est un mauvais choix de conception. Exemple: voter une vidéo YouTube. Vous ne voulez pas vraiment qu'une partie de la page soit bloquée pendant que vous cliquez sur les petits départs là-bas. Il vaut mieux échouer en silence. Même un message de confirmation serait excessif. Cependant, votre exemple de suppression d'e-mails serait considéré comme obligatoire pour les demandes Ajax de type blocage.
Mongo DB fait quelque chose comme ça (et cela pourrait être considéré comme un exemple d'application de bureau). Ils ont diverses "préoccupations d'écriture" pour leurs opérations, et vous pouvez le configurer à différentes valeurs pour chaque opération, allant de "revenir tout de suite et n'attendez rien" à "bloquer jusqu'à ce que vous ayez la confirmation du transfert réseau réussi et puis retournez "à" attendre que le contenu soit correctement programmé pour l'écriture sur disque sur la machine distante avant votre retour ". De toute évidence, si vous créez un client lourd de bureau (comme C++) à l'aide du pilote Mongo, vous définiriez le souci d'écriture le plus léger pour les opérations db de "criticité" minimale (comme la recherche de nouveaux e-mails), et d'autres sur des problèmes d'écriture plus stricts. .
Bien que je vois l'utilité d'un Ajax non bloquant, je suis d'accord avec vous que cela se produit trop. À un moment donné, il y avait au moins un site célèbre de "réseautage social" qui ferait cela pour le téléchargement de photos. Vous aviez choisi votre photo à télécharger et puis bam, tout de suite cela vous dirait que c'est fait, et puis bien sûr le lendemain lorsque vous vouliez ajouter quelques photos supplémentaires (ou utiliser dessus que vous pensiez avoir déjà ajoutées), il n'a jamais été trouvé. Plus tard, ils ont abandonné cela et ont en fait pris le temps d'attendre la réponse (et vous receviez en effet parfois des messages comme "échec du téléchargement de la photo, essayez plus tard").