これは、別のspine.jsの質問に関する議論中に出てきました:これはその質問とは大きく異なるため、SOの「投稿ごとに1つの質問」ポリシーを支持し、これを新しい質問として分岐します。
@ numbers1311407はそれを述べました
spinjs はリクエストをキューに入れ、連続して送信します。連続する各リクエストは、前のリクエストが完了した後にのみ行われます。
しかし、それは間違っているようです！Spine がクライアントからのすべての POSTS (たとえば) をこれほどまでに制御してシーケンシャル化する必要があるのはなぜですか? 投稿が関連する URI にある場合はどうなりますか? Spine が各クライアントのすべての POST を順次処理することによってある程度の健全性を達成しようとしても、異なるクライアントから発生する同時発生の競合する POSTS を防ぐ方法はまだありません。それで、なぜわざわざ？
しかし、それは間違っているようです！
スパインの設計目標、MacCaw が「非同期 UI」と呼ぶもの (関連する質問でリンクしたブログ投稿のタイトル) の実現を考えると、それは理にかなっています。このパラダイムは、ユーザー エクスペリエンスから従来の要求/応答パターンの痕跡をすべて排除しようとします。グラフィックを「ロード」する必要はもうありません。即座に反応するユーザー インタラクション。
このパラダイムは、開発への異なるアプローチを期待しています。サーバーへの永続化は、通常の状況では決して失敗しないバックグラウンド スレッドになります。
これは、通常の状況では、アプリのロジックが、spine によるリクエストの順序やスケジューリングに依存したり、気にしたりしてはならないことを意味します。
アプリがサーバーの応答に大きく依存している場合、spine は間違ったライブラリである可能性があります。
Spine がクライアントからのすべての POSTS (たとえば) をこれほどまでに制御してシーケンシャル化する必要があるのはなぜですか?
スパインの非ブロック設計哲学により、アプリはバックボーンのような別のライブラリにあるフロー制御を放棄します。これにより、リクエストが行われている間は「送信」ボタンを無効にするなどの操作を行うか、ユーザーのスパム送信を防ぐことができます。冪等でないリクエストを持つサーバー。
たとえば、スパインのModel#saveはすぐに返され、クライアントに関する限り、サーバーがリクエストを受け取る前にすでに発生しています。これは、spinejsが適切に処理されることを保証するために、要求が来た順序で収集および処理する必要があることを意味します。ユーザーが新しいレコードの「保存」ボタンを押し込んでいるとします。最初のクリックで POST が送信され、2 回目のクリックで PUT が送信されます。しかし、ボタンをスパムするユーザーは、このことを知りませんし、気にもしません。Spine は、PUT が送信される前に POST が正常に完了することを確認する必要があります。そうしないと、クライアントに問題が発生します。
ノンブロッキング UI 入力の順序の機密性と、アプリが永続化レイヤーに過度に関与してはならないという最初のポイントを組み合わせると、spinejs がリクエストをシリアル化する理由を理解し始めることができます。
Spine が各クライアントのすべての POST を順次処理することによってある程度の健全性を達成しようとしても、異なるクライアントから発生する同時発生の競合する POSTS を防ぐ方法はまだありません。それで、なぜわざわざ？
ソリューションのポイントは、単一のクライアントに一貫性のある、ある程度ユーザー エラーのない UI エクスペリエンスを提供することです。たとえば、クライアントがレコードを作成、更新、削除する場合、spine はこれらすべてのリクエストがサーバーに正しく適切な順序で送信されるようにする必要があります。クライアント間で競合する投稿を処理することは別の問題であり、リクエスト キューのポイントではありません。