ruby on rails 4 - Confusión sobre la elección de Faye o Rails 4 Actioncontroller:: Live

ruby-on-rails-4 websocket (1)

Ya he usado Faye con Ruby On Rails, es casi a un costo para mí, porque estoy ejecutando Faye sobre otro servidor conectado a mi aplicación Rails.

Sin embargo, he enfrentado algunos problemas, como cuando una consulta demora demasiado en el servidor Rails, después de un tiempo, la conexión Faye fallaría y generaría una excepción.

Ahora, lo que estoy buscando en el Actioncontroller :: Live, la mayoría de las implementaciones están usando Redis, que será un poco costoso para mi inicio, sin embargo, me di cuenta de que no puedo suscribir / publicar cosas de estilo con el Actioncontroller :: Live .

Mi pregunta: ¿debo pasar a Actioncontroller :: Live o a Faye? Si bien estas son las cosas que quiero lograr:

Actualizaciones después de comentar / feed
Sistema de notificación, basado en pub / sub, similar a Faye.
Manejo de excepciones
Escalabilidad> Más usuarios más conexiones

Sé que Faye usa Bayeux vs ActionController :: live usa SSE / HTTP. ¿Debo considerar algo relacionado con Socket.IO? SockJS?

Ya he leído algunas de las preguntas sobre este tema aquí como: ¿ Reemplazar Faye con eventos del lado del servidor de Rails 4? Faye VS rieles 4 streaming? Pero necesito más información:

Aquí hay algunas notas sobre por qué me quedaría con Faye, lo que podría acercarle a una respuesta a esta pregunta:

Compatibilidad del navegador

A medida que lee la pregunta relacionada de , Faye tiene una mejor compatibilidad con el navegador.

Estabilidad

La funcionalidad de Rails :: Live aún no parece ser muy estable. Actualmente hay un desarrollo activo en Rails SSE. Como ejemplo, es bastante improbable que este problema no le afecte.

Roscado y bloqueo vs no bloqueo asíncrono

¿Utiliza multihilo en su aplicación? Si no lo haces, definitivamente no lo introduciría solo para Rails :: Live, ya que abre la posibilidad de problemas y limitaciones de las opciones de servidor que no son threadsafe.

Si tiene subprocesos múltiples, cada cliente mantendrá un subproceso abierto a su aplicación. Si te quedas sin hilos, tu aplicación dejará de responder. Considere la cantidad de subprocesos que necesita para atender las horas pico con usuarios que tienen varias pestañas abiertas en el navegador, o incluso ataques de DOS donde alguien abre una gran cantidad de conexiones inactivas de SSE / websocket para alcanzar su máximo y eliminar su aplicación. Si configura una gran cantidad de subprocesos máximos para admitir muchas conexiones inactivas, abre la posibilidad de tener tantos subprocesos no inactivos que podrían tener sus propios problemas. Sin SSE / websockets y sin cometas / sondeo largo es mucho más seguro para bloquear aplicaciones. Por lo que entiendo, su configuración ejecuta Faye por separado. El servidor Faye ejecuta Ruby EventMachine o Node.js, que son asíncronos no bloqueantes y no usan un hilo para cada conexión abierta. Puede manejar una gran cantidad de conexiones concurrentes sin problemas.

Mi opinión es que una aplicación web Rails de bloqueo normal con un servidor asíncrono no bloqueador separado para conexiones que permanecen abiertas (para pasar mensajes y hacer que la aplicación esté en funcionamiento) es lo mejor de ambas configuraciones. Esto es lo que tienes con Rails + Faye.

Actualización : Actioncable se anunció en Railsconf 2015. Se ejecuta sin bloqueo como se describe anteriormente, pero es una solución oficial integrada de Rails. Tener una estructura única con una comunidad masiva, un manejador de conexión integrado y sin bloqueo para websockets que puede ejecutar y configurar por separado mientras todo funciona "listo para usar" es una gran ventaja de Rails.

De Action Cable readme : Action Cable se alimenta de una combinación de EventMachine y subprocesos. La estructura de la infraestructura necesaria para el manejo de la conexión se maneja en el bucle EventMachine, pero el trabajo del canal real, especificado por el usuario, se maneja en un hilo Ruby normal. Esto significa que puedes usar todos tus modelos de Rails normales sin ningún problema, siempre y cuando no hayas cometido ningún pecado de seguridad.

Para obtener más información, puede leer sobre ActionCable y la arquitectura subyacente .