非表示はどの程度安全ですかAJAXパフォーマンスを偽るリクエストですか？
非表示のリクエストとはAJAXリクエストですか？
Hidden AJAXユーザーのアクションをすぐに発生させるように設計されたリクエストの使用の増加に気づきました。このタイプのAJAXを参照します=ノンブロッキングとしてリクエストします。これは、AJAXリクエストが発生していることをユーザーに気づかれずに行われたリクエストであり、バックグラウンドで実行され、その操作はサイレントです（指定する詳細はありません） AJAX call）が正常に完了した場合の目標は、操作が実際には完了していないときにすぐに発生したように見せることです。
以下は非ブロッキングの例ですAJAX request;
- ユーザーがメールのコレクションで[削除]をクリックします。アイテムは受信トレイからすぐに消え、他の操作を続行できます。一方、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アプリケーションはそのように動作しています。
ノンブロッキングを使用するこれらのWebサイトはAJAX呼び出しを使用して応答性の高いアプリケーションをシミュレートしていますが、高速に表示されるという犠牲を払って不要なリスクを負っていますか？
これは、競争力を維持するために全員が従うべき設計パターンですか？
実際の応答性ほど「偽の」パフォーマンスではありません。それが人気がある理由はいくつかあります：
- 今日のインターネット接続はかなり信頼できます。 AJAX=リクエストが失敗するリスクは非常に低いです。
- 実行される操作は、実際には安全上重要ではありません。メールがサーバーで削除されない場合、最悪の場合、次にページにアクセスしたときに再度削除する必要があります。
- リクエストが失敗した場合にアクションを取り消すようにページを設計できますが、サーバーへの接続が切断されていることを意味するので、それほど微妙である必要はありません。 「接続が失われました。最近の変更を保存できません。しばらくしてからもう一度お試しください」と言う方が簡単です。
- 保留中の1つのAJAX=リクエストのみを許可するようにページを設計できます。これにより、サーバーからの状態の同期が取れなくなることはありません。
- AJAXリクエストが保留されているときにページを閉じたり、別のページに移動しようとすると、ブラウザから警告が表示されます。
何かが機能すると想定し、リモート側で失敗した場合にエラーを表示することは、サーバーからの応答があるまでユーザーが他のことをするのをブロックするよりもはるかにユーザーフレンドリーです。
電子メールクライアントは、実際にはgreatの例です。5つの電子メールのリストがあり、一番上のリストが選択されていると、 DEL 最初の3つの電子メールが3回削除されます。 「ノンブロッキングAJAX」を使用すると、これは正常に機能します。キーを押すたびに、選択したメールがすぐに削除されます。何かがうまくいかない場合はエラーが表示され、適切に削除されていないメールが再度表示されますOR矛盾したローカル状態を取り除くためにページがリロードされます。
つまり最も一般的なケース-それは成功です-使いやすさが向上します。 まれなケース-失敗-使いやすさが低下します（削除された要素が再び表示されるか、アプリケーションが「再起動」されます）。ただし、アプリケーションを作成するときは、通常、エラーの場合。
ユーザーは、ソフトウェアが舞台裏で何をしているのかを気にしません。彼らは自分の行動に目に見える影響を与え、自分のペースで作業できるようにしたいと考えています。
メールの削除など、クライアント側でアクションが成功した場合、サーバー側でもアクションを成功させるのはあなたの仕事です。削除が失敗したのはなぜですか？なんらかの制限によるものである場合（たとえば、アーカイブされたメールを削除することはできません）、ユーザーにそのことを通知する必要がありますbeforeアクションが失敗しました。
エラーの原因がさらに深刻なものである場合（データベースのクラッシュとしましょう）、操作を保存し、システムが再起動したときに再試行する方法が必要です。
これを管理する良い例は、Facebookがチャットを処理する方法です。ユーザーが突然切断するのを防ぐ方法はありません。つまり、ユーザーが離れる前に送信したメッセージを読むことができなくなります。エラーを表示する代わりに、システムはそれらのメッセージをすべて保存し、ユーザーが戻ってきたときにそれらを使用できるようにします。データは失われません。
2つのオプションの間で妥協することができます。たとえば、ユーザーがメールを削除した場合、サーバーから確認が得られるまでメールに赤または灰色のマークを付け、その後リストから削除することができます。ユーザーは、1つのアクションが保留中であっても他のことを実行できるため、ブロックはしませんが、アクションがまだコミットされていないことをユーザーに少し思い出させます。
Amazon AWSはこのアプローチを採用しています。インスタンスを停止/開始すると、それを選択できるようにするチェックボックスがスピナーに変わります（そのため、数秒間は何もできません）がブロックされません他のインスタンスとの相互作用。
これは、従来のサイトよりも、アプリケーションのように動作し、ブラウザーでより多くの処理（フォームデータの検証など）を実行するWebサイトが増えると思います。あなたのコードが信頼でき、通常の条件下で成功することが期待できる限り、それほど問題はないと思います。
「JavaScriptコードがAJAX要求の失敗を検出したのは現時点です。スクリプトはエラーメッセージを表示する可能性がありますが、現時点では無意味です。」
なぜそれは無意味であるべきですか？メールのリストに戻って、もう一度削除することができます。代わりに待つのはなぜですか？実際には「リスク」はあまりなく、高速であるように「見える」わけではなく、実際には高速に動作します。では、アクティビティが「クリティカル」でない場合、なぜ遅くなるのでしょうか。
私の2cは、「非ブロッキング」のAjax操作など、設計の選択が不適切な状況がある場合です。例：YouTube動画に投票する。小さな開始点をクリックしている間、ページのどの部分もブロックされたくありません。黙って失敗する方がいいです。確認メッセージでもやりすぎです。ただし、メールの削除を使用した例では、ブロッキングタイプのAjaxリクエストでは必須と見なされます。
Mongo DBはそのようなことを行います（これはデスクトップアプリケーションの例と見なすことができます）。オペレーションにはさまざまな「書き込みの懸念」があり、「すぐに戻って何も待たない」から「ネットワーク転送が成功したことを確認するまでブロックする」まで、オペレーションごとに異なる値に設定できます。次に、「戻る前に、リモートマシンでのコンテンツのディスク書き込みが適切にスケジュールされるまで待機します」に戻ります。明らかに、Mongoドライバーを使用してデスクトップシッククライアント（C++のような）を作成する場合、最小限の「重要度」（新しい電子メールのチェックなど）のdb操作、およびより厳密な書き込みの懸念については、最も軽い書き込みの懸念を設定します。 。
ノンブロッキングAjaxの有用性はわかりましたが、あまりにも多くのことが起こっていることには同意します。ある時点で、写真のアップロードのためにこれを行う有名な「ソーシャルネットワーキング」サイトが少なくとも1つありました。アップロードする写真を選択してから、すぐにそれが完了したことを通知し、翌日さらに写真を追加したいとき（または、すでに追加したと思っているときに使用するとき）にそれを確認します。見つからなかった。後で彼らはこれをあきらめ、実際に応答を待つのに時間をかけました（実際、「写真をアップロードできませんでした。後で試す」などのメッセージが表示されることもあります）。