Pros y contras de usar el Apio vs RQ [cerrado]

Esto es lo que he encontrado al tratar de responder a esta misma pregunta. Probablemente no es exhaustivo, e incluso puede ser inexacto en algunos puntos.

En resumen, RQ está diseñado para ser más simple. El apio está diseñado para ser más robusto. Ambos son excelentes.

• Documentación. La documentación de RQ es completa sin ser compleja, y refleja la simplicidad general del proyecto - nunca te sientes perdido o confundido. Documentación del apio también es integral, pero espere volver a visitarlo bastante cuando esté configurando las cosas por primera vez, ya que hay demasiadas opciones para internalizar

• Monitoreo. La flor de apio y el RQ dashboard son muy simples de configurar y le brindan al menos el 90% de toda la información que desearía

• Soporte de broker. Apio es el claro ganador, RQ solo apoya a Redis. Esto significa menos documentación sobre "qué es un corredor", pero también significa que no puede cambie de brokers en el futuro si Redis ya no trabaja para usted. Por ejemplo, Instagram consideró tanto Redis como RabbitMQ con Apio. Esto es importante porque diferentes corredores tienen diferentes garantías, por ejemplo, Redis no puede (al momento de escribir) garantizar al 100% que sus mensajes se entreguen.

• Colas prioritarias. El modelo de cola de prioridad RQs es simple y efectivo: los trabajadores leen las colas en orden. El apio requiere girar varios trabajadores para consumir desde diferentes colas. Ambos enfoques funcionan

• Soporte del sistema operativo. Celery es el claro ganador aquí, ya que RQ solo se ejecuta en sistemas que admiten fork, por ejemplo, sistemas Unix

• Soporte de idiomas. RQ solo soporta Python, mientras que Celery te permite enviar tareas de un idioma a otro

• API. Apio es extremadamente flexible (múltiples backends de resultados, buen formato de configuración, soporte de lienzo de flujo de trabajo) pero, naturalmente, esta potencia puede ser confusa. Por por el contrario, la api RQ es simple.

• Soporte de subtareas. Apio admite subtareas(por ejemplo, crear nuevas tareas desde tareas existentes). No se si RQ lo hace

• Comunidad y Estabilidad. El apio es probablemente más establecido, pero ambos son proyectos activos. Al escribir este artículo, Apio tiene ~3500 estrellas en Github mientras que RQ tiene ~2000 y ambos proyectos muestran un desarrollo activo

En mi opinión, el apio no es tan complejo como su reputación podría llevarle para creer, pero usted tendrá que RTFM.

Entonces, ¿por qué alguien estaría dispuesto a cambiar el apio (posiblemente más completo) por RQ? En mi mente, todo se reduce a la simplicidad. Al restringirse a Redis + Unix, RQ proporciona una documentación más simple, una base de código más simple y una API más simple. Esto significa que usted (y los contribuyentes potenciales a su proyecto) puede centrarse en el código que le importa, en lugar de tener que mantener los detalles sobre el sistema de cola de tareas en su memoria de trabajo. Todos tenemos un limite cuántos detalles pueden estar en nuestra cabeza a la vez, y al eliminar la necesidad de mantener los detalles de la cola de tareas allí, RQ permite volver al código que le importa. Esa simplicidad viene a expensas de características como colas de tareas entre idiomas, amplio soporte del sistema operativo, garantías de mensajes 100% confiables y capacidad para cambiar de agente de mensajes fácilmente.