The result service in docker-compose.py

Hello, I really like this boilerplate a lot but am really curious about what does the result service in the docker-compose.yml do? is it an alternative broker to rabbitmq broker service or something else? Also is there a way to add a celery beat service to the docker-compose setup.

Hi @Mzekri-madar, thanks for using the boilerplate!

result is the Celery task result backend. It's complementary to the broker:

Adding a Celery beat to the docker-compose.yml is doable, but since Docker is used for development in this boilerplate we didn't do it. We do have Celery beat on the Heroku's Procfile though, so you can grab this command and try adapting it to the docker-compose.yml:

django-react-boilerplate/Procfile

Line 3 in ff62d93

    
           beat: REMAP_SIGTERM=SIGQUIT celery --workdir backend --app={{project_name}} beat -S redbeat.RedBeatScheduler --loglevel=info

Closing the issue for now, let me know if you have any further questions.

@fjsj thank you for your reply it was really helpful!

I just have one more question, Since Rabbitmq is being used as the broker in the docker setup, does replacing it with Redis as both the result backend and the broker does not cause any issues or do they need to be in a separate containers?

@Mzekri-madar I think it's fine to use a single Redis as both broker and result, but note the Celery docs recommend RabbitMQ as a broker:

From Celery FAQ docs:

Do I have to use AMQP/RabbitMQ?
Redis as a broker won’t perform as well as an AMQP broker, but the combination RabbitMQ as broker and Redis as a result store is commonly used. If you have strict reliability requirements you’re encouraged to use RabbitMQ or another AMQP broker.

Also, in another section about brokers:

Note: RabbitMQ (as the broker) and Redis (as the backend) are very commonly used together. If more guaranteed long-term persistence is needed from the result store, consider using PostgreSQL or MySQL (through SQLAlchemy), Cassandra, or a custom defined backend.