Dependencies in lifespan #11742
Replies: 2 comments 1 reply
-
It looks like the |
Beta Was this translation helpful? Give feedback.
-
I do not think we should implement this straightforward without conceptions of lifetime Scopes. Created objects are now cached within span of single event. But, there were no nested spans. All requests are processed during single life span, I believe that they should share cache. At the same time we do not have to create a dependency per-message in websocket - we have a single object per whole connection. So, from my point of view - there should be some objects that are created once per app, others - once per websocket, rest - once per message/request. Thay can depende on each other. I have this implemented in dishka but the idea can be adopted. The other point here is that lifespan is actually the whole application lifetime. What is injected here will be finalized only on termination. Opposite to this were |
Beta Was this translation helpful? Give feedback.
-
Here's a hacky way to use dependencies in a lifespan function:
This could be done in a more appropriate way by introducing a new request type with
scope["type"] == "lifespan"
and skipping params which don't make sense in the lifecycle method (i.e. don't try to parse fields from path, etc.) Not sure if it's worth the effort but I think it will fit FastAPI's API design better than just exposing Starlette's lifecycle implementation!Beta Was this translation helpful? Give feedback.
All reactions