Фэй против Socket.IO (и Джаггернаута)

Раскрытие информации: я являюсь автором Фэй.

1. Что касается Фэй, все, что ты сказал, правда.
2. Фэй реализует большую часть Bayeux, единственное, чего сейчас не хватает, - это каналы обслуживания, в полезности которых я еще не убедился. В частности, Faye разработан для обеспечения совместимости с эталонной реализацией Bayeux CometD, которая имеет большое значение для следующего.
3. Conceptually, yes: Faye could use Socket.IO. In practise, there are some barriers to this:
   • I've no idea what kind of server-side support Socket.IO requires, and the requirement that the Faye client (there are server-side clients in Node and Ruby, remember) be able to talk to any Bayeux server (and the Faye server to any Bayeux client) may be deal-breaker.
   • Bayeux предъявляет особые требования к серверам и клиентам, поддерживающим определенные типы транспорта, и говорит, как согласовывать, какой из них использовать. Он также определяет, как они используются, например, как Content-Type запроса XHR влияет на интерпретацию его содержимого.
   • Для некоторых типов обработки ошибок мне нужен прямой доступ к транспорту, например повторная отправка сообщений при повторном подключении клиента после смерти узла WebSocket.
   • Пожалуйста, поправьте меня, если я ошибаюсь - это основано на беглом просмотре документации Socket.IO.
4. Faye is just pub/sub, it's just based on a slightly more complex protocol and has a lot of niceties built in:
   • Server- and client-side extensions
   • Сопоставление шаблонов с подстановочными знаками на маршрутах каналов
   • Автоматическое переподключение, например когда WebSockets умирает или сервер отключается
   • Клиент работает во всех браузерах, на телефонах и на стороне сервера на Node и Ruby.

Фэй, вероятно, выглядит намного сложнее по сравнению с Джаггернаутом, потому что Джаггернаут делегирует больше, например он делегирует согласование транспорта в Socket.IO, а маршрутизацию сообщений - в Redis. Оба эти решения хороши, но мое решение использовать Байё означает, что я должен больше работать сам.

Что касается философии дизайна, главная цель Фэй состоит в том, чтобы она работала везде, где есть Интернет, и должна быть абсолютно простой в использовании. Начать работать с ним очень просто, но его расширяемость означает, что его можно настраивать довольно мощными способами, например, вы можете превратить его в службу push-уведомления от сервера к клиенту (то есть прекратить нажимать на нее произвольные клиенты), добавив расширения аутентификации. .

Также ведется работа над тем, чтобы сделать его более гибким на стороне сервера. Я собираюсь добавить поддержку кластеризации и сделать ядро ​​движка pub-sub подключаемым, чтобы вы могли использовать Faye в качестве веб-интерфейса без сохранения состояния для другой системы pub-sub, такой как Redis или AMQP.

Надеюсь, это было полезно.

1. AFAIK, да, помимо того факта, что Juggernaut использует только Redis для Pubsub, а не постоянство. Также означает, что клиентские библиотеки на большинстве языков уже написаны (поскольку для этого нужен только адаптер Redis).
2. Juggernaut не реализует Bayeux, а имеет очень простой настраиваемый протокол JSON.
3. Я не знаю но наверное
4. Джаггернаут очень прост и спроектирован таким образом. Хотя я не использовал Faye, из документации кажется, что у него гораздо больше возможностей, чем просто PubSub. Будучи построенным на основе Socket.IO, он также имеет свои преимущества: Juggernaut поддерживается практически во всех браузерах, как настольных, так и мобильных.

Мне будет действительно интересно, что скажет автор Фэй. Как я уже сказал, я не использовал его, и было бы здорово узнать, как он сравнивается с Джаггернаутом. Вероятно, это случай использования лучшего инструмента для работы. Если вам нужен pubsub, Juggernaut отлично с этим справится.

Фэй, конечно, могла. Еще один пример подобного проекта поверх Socket.IO:

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