パフォーマンスを偽る隠されたAJAXリクエストはどれほど安全ですか？

隠されたAJAXリクエストとは何ですか？

ユーザーのアクションがすぐに発生するように見えるように設計された非表示のAJAXリクエストの使用が増加していることに気付きました。このタイプのAJAXリクエストを非ブロッキングと呼びます。これは、ユーザーに発生を認識せずに行われたAJAXリクエストであり、バックグラウンドで実行され、操作はサイレントです（AJAX呼び出しが正常に完了したことを示す詳細はありません）。目標は、操作が実際に終了していないときにすぐに発生したように見えるようにすることです。

ノンブロッキングAJAXリクエストの例を次に示します。

• ユーザーがメールのコレクションで[削除]をクリックします。アイテムは受信トレイからすぐに消え、他の操作を続行できます。一方、AJAXリクエストはバックグラウンドでアイテムの削除を処理しています。
• ユーザーが新しいレコードのフォームに入力します。保存をクリックします。新しいアイテムがリストにすぐに表示されます。ユーザーは引き続き新しいレコードを追加できます。

明確にするために、AJAX要求をブロックする例を次に示します。

• ユーザーがメールのコレクションで[削除]をクリックします。砂時計カーソルが表示されます。AJAX要求が行われ、応答すると砂時計カーソルがオフになります。ユーザーは、操作が完了するまで1秒待つ必要があります。
• ユーザーが新しいレコードのフォームに入力します。保存をクリックします。AJAXローダーをアニメーション化すると、フォームが灰色に変わります。「データが保存されました」というメッセージが表示され、新しいレコードがリストに表示されます。

上記の2つのシナリオの違いは、非ブロッキングAJAXセットアップでは動作のフィードバックが提供されないことと、ブロッキングAJAXセットアップでは提供されることです。

隠されたAJAXリクエストのリスク

このスタイルのAJAX要求の最大のリスクは、AJAX要求が失敗したときにWebアプリケーションがまったく異なる状態になる可能性があることです。

たとえば、非ブロッキングの例。

• ユーザーは多数のメールを選択します。削除ボタンをクリックします。操作はすぐに行われるように見えます（項目はリストから消えます）。次に、ユーザーは[作成]ボタンをクリックして、新しいメールの入力を開始します。この時点で、JavaScriptコードがAJAXリクエストが失敗したことを発見します。スクリプトはエラーメッセージを表示する可能性がありますが、現時点では本当に意味がありません。

または、ブロッキングの例。

• ユーザーは多数のメールを選択します。削除ボタンをクリックします。砂時計が見えますが、操作は失敗します。「error。blah blah blah」というエラーメッセージが表示されます。それらは電子メールのリストに戻り、削除したい電子メールが選択されたままです。彼らは再びそれらを削除しようとする可能性があります。

ノンブロッキングAJAXリクエストを実行するための他の技術的リスクもあります。ユーザーはブラウザを閉じ、別のWebサイトに移動し、現在のWebの別の場所に移動して、エラー応答のコンテキストを無意味にすることができます。

それで、なぜそんなに人気が出るのでしょうか？

Facebook、Google、Microsoftなど。これらの大規模なドメインはすべて、非ブロッキングAJAXリクエストを使用して、操作が即座に実行されているように見せるようになっています。また、保存ボタンや送信ボタンのないフォームエディタが増えています。フィールドを出るかEnterキーを押すとすぐに。値が保存されます。プロフィールが更新されたというメッセージや保存手順はありません。

AJAXリクエストは確実ではなく、完了するまで成功として扱われるべきではありませんが、多くの主要なWebアプリケーションはそのように動作しています。

ノンブロッキングAJAX呼び出しを使用するこれらのWebサイトは、レスポンシブアプリケーションをシミュレートし、高速に表示されるという犠牲を払って不要なリスクを冒していますか？

これは、競争力を維持するために私たち全員が従うべき設計パターンですか？

実際の応答性ほど「偽」のパフォーマンスではありません。人気がある理由はいくつかあります。

• 現在、インターネット接続はかなり信頼できます。AJAXリクエストが失敗するリスクは非常に低いです。
• 実行される操作は、実際には安全上重要ではありません。サーバーでメールが削除されない場合、最悪の事態は、次にページにアクセスしたときに再度削除する必要があることです。
• 要求が失敗した場合にアクションを取り消すようにページを設計できますが、サーバーへの接続が切断されることを意味するため、それほど微妙である必要はありません。「接続が失われました。最近の変更を保存できません。しばらくしてからもう一度お試しください」と言う方が簡単です。
• 保留中のAJAXリクエストを1つだけ許可するようにページを設計することができるため、サーバーから状態が同期しなくなることはありません。
• AJAXリクエストが保留中のときにページを閉じたり、ページから移動しようとすると、ブラウザは警告を表示します。

何かが機能すると仮定し、リモート側で失敗した場合にエラーを表示することは、サーバーからの応答があるまでユーザーが他の操作をブロックするよりもはるかにユーザーフレンドリーです。

実際には、電子メールクライアントはこれの優れた例です。5つの電子メールを含むリストがあり、一番上の電子メールを選択すると、DEL3回ヒットすると最初の3つの電子メールが削除されます。「ノンブロッキングAJAX」では、これは正常に機能します。キーを押すたびに、選択した電子メールがすぐに削除されます。何か問題が発生した場合、エラーが表示され、正しく削除されていない電子メールが再び表示されるか、ページが再ロードされて一貫性のないローカル状態が取り除かれます。

そのため、最も一般的なケース -成功-では、使いやすさが向上します。では珍しいケース -故障-ユーザビリティが低下している（再び要素ショーを削除したり、アプリケーションを「再起動」される）がありますが、通常は一般的なケースのために、ないエラーが発生した場合の最高の使いやすさを持つようにしたいアプリケーションを作成するとき。

ユーザーは、あなたのソフトウェアが舞台裏で何をしているのか気にしません。彼らは自分の行動に目に見える影響を与え、自分のペースで作業できるようにしたいのです。

メールの削除など、クライアント側でアクションが成功した場合、サーバー側でも同様に成功させるのはあなたの仕事です。削除が失敗したのはなぜですか？何らかの制限が原因である場合（たとえば、アーカイブされたメールを削除することはできません）、ユーザーはアクションが失敗する前にそのことを認識しておく必要があります。

エラーの原因がより重大なもの（データベースのクラッシュなど）である場合は、操作を保存して、システムが再起動したときに再試行する方法が必要です。

これを管理する良い例は、Facebookがチャットを処理する方法です。ユーザーが突然切断することを止める方法はありません。つまり、ユーザーが送信する前に送信したメッセージを読むことができなくなります。エラーを表示する代わりに、システムはそれらすべてのメッセージを保存し、ユーザーが戻ってきたときにそれらを利用できるようにします。データは失われません。

2つのオプションの間で妥協することができます。たとえば、ユーザーがメールを削除した場合、サーバーから確認が返されるまで赤または灰色でマークしてから、リストから削除することができます。ユーザーは、1つのアクションが保留中に他のことを実行できるため、ブロックされませんが、アクションがまだコミットされていないことをユーザーに少し思い出させます。

Amazon AWSはこのアプローチを取ります：インスタンスを停止/開始すると、それを選択できるチェックボックスがスピナーに変わります（したがって、数秒間は何もできません）が、これはあなたをブロックしません他のインスタンスとの対話。

これは、従来のサイトよりも、アプリケーションのように振る舞い、ブラウザでより多くの処理（フォームデータの検証など）を試みるWebサイトが増えてくると思います。あなたのコードが信頼でき、通常の条件下で成功することを期待できる限り、あまり問題はありません。

「この時点で、JavaScriptコードがAJAXリクエストが失敗したことを発見しました。スクリプトはエラーメッセージを表示する可能性がありますが、現時点では本当に意味がありません。」

なぜ無意味なのでしょうか？メールのリストに戻り、削除を再度実行できます。代わりに待つのはなぜですか？実際には「リスク」はあまりなく、高速に「見える」わけではなく、実際には高速に動作します。では、アクティビティが「クリティカル」でない場合、なぜ遅いのでしょうか？

私の2cは、「非ブロッキング」Ajaxオペレーションなど、設計の選択が不適切な場合があります。例：YouTubeビデオの投票。そこから始まる小さなアイコンをクリックする間、ページのどの部分もブロックされたくないのです。黙って失敗する方が良い。確認メッセージでさえも殺されてしまいます。ただし、電子メールを削除する場合の例は、ブロッキングタイプのAjaxリクエストに必須と見なされます。

Mongo DBはそのようなことをします（これはデスクトップアプリケーションの例と見なすことができます）。オペレーションにはさまざまな「懸念事項」があり、「すぐに戻って何も待たない」から「ネットワーク転送が成功したことを確認するまでブロックする」まで、オペレーションごとに異なる値に設定できます。その後、「戻る前に、コンテンツがリモートマシンのディスク書き込み用に適切にスケジュールされるまで待機する」に戻ります。明らかに、Mongoドライバーを使用してデスクトップシッククライアント（C ++など）を作成する場合、最小限の "重要度"（新しい電子メールのチェックなど）のdb操作に対して最も軽い書き込みの懸念を設定します。 。

ノンブロッキングAjaxの有用性はわかりますが、あまりにも多くのことが起こっていることに同意します。ある時点で、写真のアップロードのためにこれを行う少なくとも1つの有名な「ソーシャルネットワーキング」サイトがありました。アップロードする写真を選択してからバムし、すぐにそれが完了したことを伝え、さらに翌日あなたがいくつかの写真を追加したいとき（または既に追加したと思ったものを使用するとき）決して見つけられなかった。後で彼らはこれをあきらめ、実際に応答を待つ時間を取りました（そして、実際には「写真のアップロードに失敗しました。後で試してください」などのメッセージが表示されることがあります）。