Faye vs. Socket.IO (und Juggernaut)

Socket.IO scheint die beliebteste und aktivste WebSocket-Emulationsbibliothek zu sein. Juggernaut verwendet es, um ein komplettes Pub / Sub-System zu erstellen.

Faye ist auch beliebt und aktiv und verfügt über eine eigene Javascript-Bibliothek, wodurch die gesamte Funktionalität mit der von Juggernaut vergleichbar ist. Juggernaut verwendet Node für seinen Server, und Faye kann entweder Node oder Rack verwenden. Juggernaut verwendet Redis für die Persistenz ( Korrektur: Redis für Pub / Sub), und Faye behält nur den Status im Speicher.

1. Ist alles oben korrekt?
2. Faye sagt, dass es Bayeux implementiert - ich denke, Juggernaut tut dies nicht -, weil Juggernaut auf einer niedrigeren Ebene ist (IE, ich kann Bayeux mit Juggernaut implementieren).
3. Könnte Faye zur Verwendung der Javascript-Bibliothek des Socket.IO-Browsers wechseln, wenn dies gewünscht wird? Oder machen ihre Javascript-Bibliotheken grundlegend andere Dinge?
4. Gibt es andere architektonische / gestalterische / philosophische Unterschiede zwischen den Projekten?

Offenlegung: Ich bin der Autor von Faye.

1. In Bezug auf Faye ist alles, was Sie gesagt haben, wahr.
2. Faye implementiert den größten Teil von Bayeux. Das einzige, was derzeit fehlt, sind Servicekanäle, von deren Nützlichkeit ich noch nicht überzeugt bin. Insbesondere ist Faye so konzipiert, dass es mit der CometD-Referenzimplementierung von Bayeux kompatibel ist, die einen großen Einfluss auf Folgendes hat.
3. Konzeptionell ja: Faye könnte Socket.IO verwenden. In der Praxis gibt es hierfür einige Hindernisse:
   • Ich habe keine Ahnung, welche Art von serverseitiger Unterstützung Socket.IO benötigt, und die Anforderung, dass der Faye-Client (es gibt serverseitige Clients in Node und Ruby, denken Sie daran) mit jedem Bayeux-Server (und dem Faye) kommunizieren kann Server für jeden Bayeux-Client) kann ein Deal-Breaker sein.
   • Bayeux hat spezielle Anforderungen, dass Server und Clients bestimmte Transporttypen unterstützen, und gibt an, wie zu verhandeln ist, welche verwendet werden sollen. Außerdem wird angegeben, wie sie verwendet werden, z. B. wie sich der Inhaltstyp einer XHR-Anforderung auf die Interpretation ihres Inhalts auswirkt.
   • Für einige Arten der Fehlerbehandlung benötige ich direkten Zugriff auf den Transport, z. B. das erneute Senden von Nachrichten, wenn ein Client nach dem Absterben eines Node WebSocket erneut eine Verbindung herstellt .
   • Bitte korrigieren Sie mich, wenn ich etwas falsch gemacht habe - dies basiert auf einem flüchtigen Scan der Socket.IO-Dokumentation.
4. Faye ist nur Pub / Sub, es basiert nur auf einem etwas komplexeren Protokoll und hat viele Feinheiten eingebaut:
   • Server- und clientseitige Erweiterungen
   • Wildcard-Pattern-Matching auf Kanalrouten
   • Automatische Wiederverbindung, z. B. wenn WebSockets sterben oder der Server offline geht
   • Der Client funktioniert in allen Browsern, auf Telefonen und serverseitig auf Node und Ruby

Faye sieht im Vergleich zu Juggernaut wahrscheinlich viel komplexer aus, da Juggernaut mehr delegiert, z. B. Transportverhandlungen an Socket.IO und Nachrichtenrouting an Redis. Beides sind gute Entscheidungen, aber meine Entscheidung, Bayeux zu verwenden, bedeutet, dass ich selbst mehr arbeiten muss.

Was die Designphilosophie betrifft, ist Fayes übergeordnetes Ziel, dass sie überall dort funktioniert, wo das Web verfügbar ist, und dass sie absolut trivial sein sollte. Der Einstieg ist sehr einfach, aber aufgrund seiner Erweiterbarkeit kann er auf sehr leistungsstarke Weise angepasst werden. Sie können ihn beispielsweise durch Hinzufügen von Authentifizierungserweiterungen in einen Server-zu-Client-Push-Dienst verwandeln (dh verhindern, dass beliebige Clients darauf pushen) .

Es wird auch daran gearbeitet, es auf der Serverseite flexibler zu gestalten. Ich möchte Clustering-Unterstützung hinzufügen und die Kern-Pub-Sub-Engine steckbar machen, damit Sie Faye als zustandsloses Web-Frontend für ein anderes Pub-Sub-System wie Redis oder AMQP verwenden können.

Ich hoffe das war hilfreich.

1. AFAIK, ja, abgesehen davon, dass Juggernaut Redis nur für Pubsub verwendet, nicht für Beharrlichkeit. Dies bedeutet auch, dass Client-Bibliotheken in den meisten Sprachen bereits geschrieben wurden (da nur ein Redis-Adapter benötigt wird).
2. Juggernaut implementiert Bayeux nicht, sondern verfügt über ein sehr einfaches benutzerdefiniertes JSON-Protokoll
3. Keine Ahnung, wahrscheinlich
4. Juggernaut ist sehr einfach und so konzipiert. Obwohl ich Faye nicht verwendet habe, sieht es aus den Dokumenten so aus, als hätte es viel mehr Funktionen als nur PubSub. Juggernaut wird auf Socket.IO aufgebaut und hat auch Vorteile. Es wird in praktisch jedem Browser unterstützt, sowohl auf dem Desktop als auch auf dem Handy.

Ich werde wirklich interessiert sein, was Fayes Autor zu sagen hat. Wie gesagt, ich habe es nicht benutzt und es wäre toll zu wissen, wie es mit Juggernaut verglichen wird. Es ist wahrscheinlich der Fall, das beste Werkzeug für den Job zu verwenden. Wenn es Pubsub ist, den Sie brauchen, macht Juggernaut das sehr gut.

Faye konnte es auf jeden Fall. Ein weiteres Beispiel für ein ähnliches Projekt auf Socket.IO:

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