Faye vs. Socket.IO (e Juggernaut)
Socket.IO parece ser a biblioteca de emulação WebSocket mais popular e ativa. Juggernaut o usa para criar um sistema pub / subs completo.
Faye também é popular e ativo e tem sua própria biblioteca javascript, tornando sua funcionalidade completa comparável ao Juggernaut. Juggernaut usa o nó para seu servidor e Faye pode usar o nó ou o rack. Juggernaut usa Redis para persistência ( correção: ele usa Redis para pub / sub), e Faye apenas mantém o estado na memória.
Tudo acima está correto?
Faye diz que implementa Bayeux - acho que Juggernaut não faz isso - é porque Juggernaut é de nível inferior (ou seja, posso implementar Bayeux usando Juggernaut)
Faye poderia passar a usar a biblioteca javascript do navegador Socket.IO, se quisesse? Ou suas bibliotecas javascript fazem coisas fundamentalmente diferentes?
Existem outras diferenças arquitetônicas / de design / filosofia entre os projetos?
websocket publish-subscribe juggernaut bayeux socket.io
— John Bachir
Por precaução, Juggernaut foi descontinuado! Leia por que blog.alexmaccaw.com/killing-a-library .
— Maziyar,
Os eventos enviados pelo servidor HTML 5 parecem ser a alternativa recomendada de acordo com o autor do Juggernaut
— Harindaka
Divulgação: Eu sou o autor de Faye.
Quanto a Faye, tudo o que você disse é verdade.
Faye implementa a maior parte do Bayeux, a única coisa que falta agora são os canais de serviço, dos quais ainda não estou convencido da utilidade. Em particular, Faye é projetado para ser compatível com a implementação de referência CometD de Bayeux, que tem uma grande influência no seguinte.
Conceitualmente, sim: Faye poderia usar Socket.IO. Na prática, existem algumas barreiras para isso:
Não tenho ideia de que tipo de suporte do lado do servidor Socket.IO requer, e o requisito de que o cliente Faye (há clientes do lado do servidor em Node e Ruby, lembre-se) seja capaz de se comunicar com qualquer servidor Bayeux (e o Faye servidor para qualquer cliente Bayeux) pode ser um disjuntor.
Bayeux tem requisitos específicos de que servidores e clientes suportem certos tipos de transporte e diz como negociar qual deles usar. Ele também especifica como eles são usados, por exemplo, como o Content-Type de uma solicitação XHR afeta como seu conteúdo é interpretado.
Para alguns tipos de tratamento de erros, preciso de acesso direto ao transporte, por exemplo, reenviar mensagens quando um cliente se reconecta depois que um Node WebSocket morre .
Por favor, corrija-me se eu entendi algo errado - isso é baseado em uma varredura superficial da documentação Socket.IO.
Faye é apenas pub / sub, é apenas baseado em um protocolo um pouco mais complexo e tem muitas sutilezas integradas:
Extensões do lado do servidor e do cliente
Correspondência de padrões curinga em rotas de canal
Reconexão automática, por exemplo, quando WebSockets morrem ou o servidor fica offline
O cliente funciona em todos os navegadores, em telefones e no lado do servidor em Node e Ruby
Faye provavelmente parece muito mais complexo em comparação com Juggernaut porque Juggernaut delega mais, por exemplo, ele delega negociação de transporte para Socket.IO e roteamento de mensagens para Redis. Ambas as decisões são boas, mas minha decisão de usar Bayeux significa que tenho que trabalhar mais sozinho.
Quanto à filosofia de design, o objetivo primordial de Faye é que funcione em todos os lugares em que a Web estiver disponível e seja absolutamente trivial para começar. É muito simples de começar, mas sua extensibilidade significa que pode ser personalizado de maneiras bastante poderosas, por exemplo, você pode transformá-lo em um serviço push de servidor para cliente (ou seja, interromper o envio de clientes arbitrários para ele) adicionando extensões de autenticação .
Também há um trabalho em andamento para torná-lo mais flexível no lado do servidor. Estou pensando em adicionar suporte a cluster e tornar o mecanismo pub-sub principal plugável para que você possa usar Faye como um front-end da Web sem estado para outro sistema pub-sub, como Redis ou AMQP.
— Jcoglan
Obrigado por uma ótima resposta. Eu não percebi a flexibilidade do protocolo Bayeux - então um cliente arbitrário deve ser capaz de conversar com servidores arbitrários / múltiplos? Você conhece algum projeto ou serviço de produção que aproveite totalmente isso?
Recentemente, mudei de Socket.IO para Faye, e devo dizer que Faye salvou meu aplicativo. Com um servidor Faye simples e um servidor médio, meu aplicativo pode lidar com 6.000 usuários simultaneamente de acordo com o google analytics
— Tan Nguyen
AFAIK, sim, além do fato de que Juggernaut só usa Redis para Pubsub, não persistência. Também significa que as bibliotecas de cliente na maioria das linguagens já foram escritas (pois só precisa de um adaptador Redis).
Juggernaut não implementa Bayeux, mas tem um protocolo JSON personalizado muito simples
Não sei provavelmente
Juggernaut é muito simples e projetado para ser assim. Embora eu não tenha usado o Faye, pelos documentos parece que ele tem muito mais recursos do que apenas PubSub. Sendo construído em cima do Socket.IO tem suas vantagens também, Juggernaut é suportado em praticamente todos os navegadores, desktop e móveis.
Estarei realmente interessado no que o autor de Faye tem a dizer. Como já disse, não o usei e seria ótimo saber como ele se compara ao Juggernaut. Provavelmente é o caso de usar a melhor ferramenta para o trabalho. Se é pubsub que você precisa, Juggernaut faz isso muito bem.
— Alex MacCaw
Obrigado por uma ótima resposta. Não sabia que o Redis era usado apenas para seus recursos de pub / sub. Me fez perguntar isto: stackoverflow.com/questions/4938520