Faye対Socket.IO（およびJuggernaut）

Socket.IOは、最も人気がありアクティブなWebSocketエミュレーションライブラリのようです。Juggernautはそれを使用して完全なpub / subシステムを作成します。

Fayeも人気がありアクティブであり、独自のJavaScriptライブラリを備えているため、Juggernautに匹敵する完全な機能を備えています。Juggernautはサーバーにノードを使用し、Fayeはノードまたはラックを使用できます。Juggernautは永続化にRedisを使用し（訂正： pub / subにRedisを使用）、Fayeは状態をメモリにのみ保持します。

1. 上記はすべて正確ですか？
2. フェイはバイユーを実装していると言います-私はジャガーノートがこれをしないと思います-それはジャガーノートが低レベルだからです（IE、私はジャガーノートを使ってバイユーを実装できます）
3. Fayeは、必要に応じて、Socket.IOブラウザのJavaScriptライブラリを使用するように切り替えることができますか？または、JavaScriptライブラリは根本的に異なることをしますか？
4. プロジェクト間に他のアーキテクチャ/デザイン/哲学の違いはありますか？

情報開示：私はフェイの作者です。

1. フェイに関しては、あなたが言ったことはすべて真実です。
2. Fayeはほとんどのバイユーを実装していますが、現時点で欠けているのはサービスチャネルだけですが、その有用性についてはまだ確信がありません。特に、Fayeは、以下に大きな影響を与えるバイユーのCometDリファレンス実装と互換性があるように設計されています。
3. 概念的には、はい：Faye は Socket.IOを使用できます。実際には、これにはいくつかの障壁があります。
   • 私はSocket.IOがどのようなサーバー側サポートを必要とするか、またFayeクライアント（NodeとRubyにはサーバー側クライアントがあることを覚えておいてください）が任意のBayeuxサーバー（およびFaye）と通信できるという要件を知りません任意のバイユークライアントへのサーバー）は、取引ブレーカーになる可能性があります。
   • バイユーには、サーバーとクライアントが特定のトランスポートタイプをサポートするという特定の要件があり、どのトランスポートタイプをネゴシエートするかについて述べています。また、XHRリクエストのContent-Typeがコンテンツの解釈にどのように影響するかなど、それらの使用方法も指定します。
   • 一部のタイプのエラー処理では、トランスポートに直接アクセスする必要があります。たとえば、ノードWebSocketの停止後にクライアントが再接続したときにメッセージを再送信します。
   • これが間違っている場合は修正してください-これはSocket.IOのドキュメントの大まかなスキャンに基づいています。
4. Fayeはただのpub / subであり、少し複雑なプロトコルに基づいており、多くの機能が組み込まれています。
   • サーバー側とクライアント側の拡張機能
   • チャネルルートでのワイルドカードパターンマッチング
   • 自動再接続、たとえばWebSocketが停止したとき、またはサーバーがオフラインになったとき
   • クライアントは、すべてのブラウザー、電話、およびノー​​ドとRubyのサーバー側で動作します

Fayeは、Juggernautに比べてはるかに複雑に見えます。Juggernautがさらに委譲するためです。たとえば、転送ネゴシエーションをSocket.IOに委任し、メッセージルーティングをRedisに委任します。これらはどちらもすばらしい決断ですが、バイユーを使用するという私の決断は、自分でもっと仕事をしなければならないことを意味します。

設計哲学に関しては、Fayeの最優先目標は、Webが利用可能なすべての場所で機能することであり、それを実現するために絶対に取るに足らないことです。私は始めるのは本当に簡単ではありませんが、その拡張性は、それを非常に強力な方法でカスタマイズできることを意味します。たとえば、認証拡張機能を追加することで、サーバーからクライアントへのプッシュサービスに変換できます（つまり、プッシュする任意のクライアントを停止できます）。 。

サーバー側でより柔軟にするための作業も進行中です。クラスタリングのサポートを追加し、コアpub-subエンジンをプラグイン可能にして、FayeをRedisやAMQPなどの別のpub-subシステムのステートレスWebフロントエンドとして使用できるようにすることを検討しています。

これがお役に立てば幸いです。

1. AFAIK、はい、Juggernautは永続性ではなく、PubsubにRedisのみを使用するという事実は別として。また、ほとんどの言語のクライアントライブラリはすでに作成されていることを意味します（Redisアダプターが必要なため）。
2. JuggernautはBayeuxを実装していませんが、非常にシンプルなカスタムJSONプロトコルを持っています
3. ダンノ、たぶん
4. ジャガーノートは非常にシンプルで、そのように設計されています。私はFayeを使用していませんが、ドキュメントからは、PubSub以外にも多くの機能があるようです。Socket.IOの上に構築されているという利点もあります。Juggernautは、デスクトップとモバイルの両方のほぼすべてのブラウザーでサポートされています。

私はフェイの作者が言っていることに本当に興味があります。私が言うように、私はそれを使用していません、そしてそれがジャガーノートとどのように比較するかを知ることは素晴らしいでしょう。それはおそらく、仕事に最適なツールを使用する場合です。必要なpubsubであれば、Juggernautはそれを非常にうまく行います。

フェイは確かにできた。Socket.IOの上にある同様のプロジェクトの別の例：

https://github.com/aaronblohowiak/Push-It