Flask-RQ2 VS rq-scheduler

From experience i would not use threads for this or any background jobs. I would use Celery or Flask-RQ2 to be your workers, you will also probably end up using them to run other tasks as you encounter the need for other jobs. They both use Redis as a broker and job store and you can use Redis for other things like caching and so many other useful features. I kind of like RQ2 more then Celery because its a little simpler but Celery has a lot more to offer, more features. RQ2 has rq-dashboard for monitoring jobs and Celery has Flower.

However, you might need to access the app’s context like how you’d do so in the Flask-RQ2 extension by using ScriptInfo from flask.cli:

For the CLI part, i recommend going with Click. Its great and already part of flask and easy to use. Other CLI libraries work too but why have more libraries. For scheduling jobs you might want to look at Flask-APScheduler. i used it in one of my projects at work for a while but ended up needing something that could scale to many more workers so had to rip it out but i didnt have a problem with it otherwise. You might want to fork Flask-APScheduler so you can update some libraries because it hasnt been touched in 2 years now or you can just use APScheduler alone. Flask-RQ2 and Celery are pretty good too but the workers need to run in separate processes and need Redis. You could use Redislite i think and with celery you could use a database as your broker, i have done it but dont recommend it.

RQ-Scheduler is another simpler alternative (rq/rq-scheduler: A lightweight library that adds job scheduling capabilities to RQ (Redis Queue) (github.com)) that appears to be good for such purposes. It's not immediately clear if it would suffer from the same issues, but it seems not (Redis manages issues with data loss well, a separate queue is used for the scheduled tasks, etc.). Is anyone aware of any drawbacks to using RQ-Scheduler for something like this?

Some thoughts: - Storing API keys in Redis with AOF and RDB persistence turned on is going to be way faster than storing those keys in Mongo. - Did you mean RQ (redis-queue)/django-rq? If so, it works well as long as you don't need a scheduler for cron-like tasks, which it doesn't include. You can add rq-scheduler for that though: https://github.com/rq/rq-scheduler - Make sure your redis instance has a password -- redis 6 supports ACLs as well - The problem with slow requests is that they tie up app server processes and usually also database connections. That may be fine with a small number of consumers, but if you point your web site at this API, you may run into problems. Consider that if an app server serving web site traffic is waiting for a slow request to your API, then both app servers are affected -- you're now holding resources on the web site and the API, effectively. - HTTP clients often use a default timeout value for requests, and it's a best practice to use such a timeout -- so you'll need to coach your partners consuming this API not to use timeouts for your API.