nodejs：Ajax対Socket.IO、賛否両論
クライアント側のすべてのAjax呼び出し（jQuery）を取り除き、代わりに永続的なソケット接続（Socket.IO）を使用することを考えました。
そのため、クライアント側とサーバー側のイベントリスナ/エミッタを使用します。
例ブラウザでクリックイベントがユーザーによってトリガーされると、クライアント側のエミッターはサーバーへのソケット接続を介してイベントをプッシュします。サーバー側リスナーは、着信イベントに反応し、「完了」イベントをクライアントにプッシュします。クライアントのリスナーは、DIV要素をフェードインすることにより、着信イベントに反応します。
それはまったく理にかなっていますか？長所短所？
一方向のメッセージを送信し、それらにコールバックを呼び出すことは非常に面倒です。
$.get('/api', sendData, returnFunction);はsocket.emit('sendApi', sendData);socket.on('receiveApi', returnFunction);よりもクリーンです
これが、dnodeとnowjsがsocket.ioの上に構築され、物事を管理しやすくした理由です。まだイベント駆動ですが、コールバックをあきらめません。
Socket.IOはクライアントとサーバー間の永続的な接続を使用するため、サーバー側にあるリソースに応じて同時接続の最大制限に達しますが、同じリソースでより多くのAjax非同期リクエストを処理できます。
Socket.IOは、主にクライアントとサーバー間のリアルタイムおよび双方向接続用に設計されており、一部のアプリケーションでは永続的な接続を維持する必要はありません。一方、Ajax非同期接続はHTTP接続セットアップフェーズを通過し、すべてのリクエストでヘッダーデータとすべてのCookieを送信する必要があります。
Socket.IOは単一のプロセスサーバーとして設計されており、バインドされているサーバーリソースによってはスケーラビリティの問題が発生する場合があります。
Socket.IOは、クライアントリクエストの結果をキャッシュする方が適切なアプリケーションにはあまり適していません。
Socket.IOアプリケーションは、SEOの最適化と検索エンジンのインデックス作成に関する問題に直面しています。
Socket.IOは標準ではなく、W3C Web Socket APIと同等ではありません。ブラウザがサポートしている場合は、現在のWeb Socket APIを使用します。リアルタイムアプリでのブラウザ間の互換性を解決するために人が作成したsocket.io古い。その学習曲線、ajax/jqueryと比較した開発者とコミュニティリソースの削減、長期メンテナンス、将来の必要性や優れたオプションの削減は、開発者チームがsocket.ioに基づいてコードを作成するかどうかに関係なく重要です。