Replies: 3 comments 1 reply
-
Just saw this is discussion 1000 in this repo. Congrats 👏🏼 |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
I see the point that integrating directly with ASGI makes the example easier to adapt. However, I think in an example tailored towards a specific framework, you should try to integrate with that framework as usual, because in that case the example would be far easier to understand for people just programming with FastAPI which have never bothered with the ASGI internals. I might be wrong here, but I think that is most. I wasnt aware you had to use an async context manager, but now I looked into the code (and learned about TaskGroups along the way) and understand why that is necessary. Still, you can use FastAPI's built in features here: # Do the basic scheduler setup here
scheduler = AsyncScheduler(data_store, event_broker)
@asynccontextmanager
async def lifespan(app: FastAPI):
async with scheduler:
await scheduler.add_schedule(tick, IntervalTrigger(seconds=1))
await scheduler.start_in_background()
yield
app = FastAPI(lifespan=lifespan) |
Beta Was this translation helpful? Give feedback.
-
I am trying to use APScheduler in my FastAPI project. When I looked at the example, I was a bit shocked on how seemingly complex the code seemed to be. Is there any specific reason to directly integrate with the ASGI instead of using FastAPI specific features? Following something I would think would also work (not tested as I am not at my PC right now, and man it is pain to write code on an iPhone):
Beta Was this translation helpful? Give feedback.
All reactions