Faye contre Socket.IO (et Juggernaut)
Socket.IO semble être la bibliothèque d'émulation WebSocket la plus populaire et la plus active. Juggernaut l'utilise pour créer un système pub/sub complet.
Faye est également populaire et actif, et possède sa propre bibliothèque javascript, ce qui rend ses fonctionnalités complètes comparables à Juggernaut. Juggernaut utilise un nœud pour son serveur et Faye peut utiliser un nœud ou un rack. Juggernaut utilise Redis pour la persistance ( correction: il utilise Redis pour pub/sub), et Faye ne garde que l'état en mémoire.
- Tout ce qui précède est-il précis?
- Faye dit qu'il implémente Bayeux - je pense que Juggernaut ne le fait pas - c'est parce que Juggernaut est de niveau inférieur (IE, je peux implémenter Bayeux en utilisant Juggernaut)
- Faye pourrait-elle passer à l'utilisation de la bibliothèque javascript du navigateur Socket.IO si elle le voulait? Ou leurs bibliothèques javascript font-elles des choses fondamentalement différentes?
- Existe-t-il d'autres différences architecturales/de conception/philosophiques entre les projets?
Divulgation: je suis l'auteur de Faye.
- En ce qui concerne Faye, tout ce que vous avez dit est vrai.
- Faye met en œuvre la majeure partie de Bayeux, la seule chose qui manque actuellement est les canaux de service, dont je n'ai pas encore été convaincu de l'utilité. En particulier, Faye est conçu pour être compatible avec l'implémentation de référence CometD de Bayeux, qui a une grande incidence sur les éléments suivants.
- Conceptuellement, oui: Faye pourrait utiliser Socket.IO. Dans la pratique, il existe certains obstacles à cela:
- Je n'ai aucune idée du type de prise en charge côté serveur requis par Socket.IO et de l'exigence que le client Faye (il y a des clients côté serveur dans Node et Ruby, rappelez-vous) puisse parler à n'importe quel serveur Bayeux (et le serveur Faye à n'importe quel client Bayeux) peut être un facteur déterminant.
- Bayeux a des exigences spécifiques pour que les serveurs et les clients prennent en charge certains types de transport, et indique comment négocier lequel utiliser. Il spécifie également comment ils sont utilisés, par exemple comment le type de contenu d'une demande XHR affecte la façon dont son contenu est interprété.
- Pour certains types de gestion des erreurs, j'ai besoin d'un accès direct au transport, par exemple renvoyer des messages lorsqu'un client se reconnecte après un Node WebSocket meurt .
- Veuillez me corriger si je me trompe - ceci est basé sur une analyse rapide de la documentation Socket.IO.
- Faye est juste pub/sub, il est simplement basé sur un protocole légèrement plus complexe et a beaucoup de subtilités intégrées:
- Extensions côté serveur et côté client
- Correspondance des caractères génériques sur les itinéraires des canaux
- Reconnexion automatique, par ex. lorsque WebSockets meurt ou que le serveur se déconnecte
- Le client fonctionne dans tous les navigateurs, sur les téléphones et côté serveur sur Node et Ruby
Faye semble probablement beaucoup plus complexe que Juggernaut parce que Juggernaut délègue plus, par ex. il délègue la négociation du transport à Socket.IO et le routage des messages à Redis. Ce sont deux bonnes décisions, mais ma décision d'utiliser Bayeux signifie que je dois faire plus de travail moi-même.
Quant à la philosophie de conception, l'objectif primordial de Faye est qu'elle devrait fonctionner partout où le Web est disponible et devrait être absolument triviale pour commencer. C'est très simple pour commencer, mais son extensibilité signifie qu'il peut être personnalisé de manière assez puissante, par exemple, vous pouvez le transformer en un service Push de serveur à client (c'est-à-dire arrêter les clients arbitraires qui y poussent) en ajoutant des extensions d'authentification .
Des travaux sont également en cours pour le rendre plus flexible côté serveur. J'envisage d'ajouter la prise en charge du clustering et de rendre le moteur pub-sub principal enfichable afin que vous puissiez utiliser Faye comme interface Web sans état pour un autre système pub-sub comme Redis ou AMQP.
J'espère que cela vous a été utile.
- AFAIK, oui, à part le fait que Juggernaut utilise uniquement Redis pour Pubsub, pas la persistance. Signifie également que les bibliothèques clientes dans la plupart des langues ont déjà été écrites (car il suffit d'un adaptateur Redis).
- Juggernaut n'implémente pas Bayeux, mais dispose plutôt d'un protocole JSON personnalisé très simple
- Je ne sais pas, probablement
- Juggernaut est très simple et conçu pour être ainsi. Bien que je n'ai pas utilisé Faye, d'après les documents, il semble qu'il ait beaucoup plus de fonctionnalités que PubSub. Être construit sur Socket.IO a aussi ses avantages, Juggernaut est pris en charge dans pratiquement tous les navigateurs, à la fois de bureau et mobiles.
Je serai vraiment intéressé par ce que l'auteur de Faye a à dire. Comme je l'ai dit, je ne l'ai pas utilisé et ce serait bien de savoir comment il se compare à Juggernaut. C'est probablement le cas de l'utilisation du meilleur outil pour le travail. Si vous avez besoin d'un pub, Juggernaut le fait très bien.
Faye le pouvait certainement. Un autre exemple d'un projet similaire sur Socket.IO: