I'm building a website which provides some information to the visitors. This information is aggregated in the background by polling a couple external APIs every 5 seconds. The way I have it working now is that I use APScheduler jobs. I initially preferred APScheduler because it makes the whole system more easy to port (since I don't need to set cron jobs on the new machine). I start the polling functions as follows:
from apscheduler.scheduler import Scheduler
apsched = Scheduler()
RuntimeError('working outside of application context')
You can use the
app.app_context() context manager to set the application context. I imagine usage would go something like this:
from apscheduler.scheduler import Scheduler def checkSecondApi(): with app.app_context(): # Do whatever you were doing to check the second API @app.before_first_request def initialize(): apsched = Scheduler() apsched.start() apsched.add_interval_job(checkFirstAPI, seconds=5) apsched.add_interval_job(checkSecondAPI, seconds=5) apsched.add_interval_job(checkThirdAPI, seconds=5)
Alternatively, you could use a decorator
def with_application_context(app): def inner(func): @functools.wraps(func) def wrapper(*args, **kwargs): with app.app_context(): return func(*args, **kwargs) return wrapper return inner @with_application_context(app) def checkFirstAPI(): # Check the first API as before
Yes it will still work. The sole (significant) difference is that your application will not be communicating directly with the world; it will be going through a reverse proxy or something via fastcgi/uwsgi/whatever. The only concern is that if you have multiple instances of the app starting, then multiple schedulers will be created. To manage this, I would suggest you move your backend tasks out of the Flask application, and use a tool designed for running tasks regularly (i.e. Celery). The downside to this is that you won't be able to use things like Flask-Mail, but imo, it's not too good to be so closely tied to the Flask ecosystem; what are you gaining by using Flask-Mail over a standard, non Flask, mail library?
Also, breaking up your application makes it much easier to scale up individual components as the capacity is required, compared to having one monolithic web application.