You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 24, 2022. It is now read-only.
Coming back at aiodine after a few months off, the initial design and API don't seem as optimal as they could be from a developer experience point of view.
Complexity: there are a lot of concepts, e.g. "provider", "consumer", "store", "provider freezing", etc. All of them seem overly complicated and potentially leaky abstractions.
The path that FastAPI took for its dependency injection mechanism seems to solve both of these problems. I'm curious at whether we could replicate the design here, although that should probably mean aiodine is spun up as a different library altogether (code-named asyncdeps below).
We should make sure depends works well with static type checkers, e.g. by casting its return value to the return value type of its function.
If we go for this style, there's one question to tackle: can we keep scopes with this API?
My intuition is that we can keep the idea of caching dependencies for reuse (which is what the "session" scope is all about), but propose a more straight-forward API.
The default behavior would be to evaluate dependencies on every call (equivalent of the current "function" scope). The behavior of the "session" scope could be obtained via an @cached marker, e.g.:
fromasyncdepsimportdepends, cached@cachedasyncdefget_hello() ->str:
print("Evaluating hello…")
return"Hello"asyncdefshow(hello: str=depends(get_hello)) ->None:
print(hello)
asyncdefmain():
awaitshow() # Prints "Evaluating hello…"awaitshow() # Nothing printed (hello already evaluated in this scope)
Besides, we can force-turn on/off caching on callees, e.g. depends(get_hello, cached=False).
Combined with a generator-based API, this would allow us to support the database provisioning use case for async web frameworks, e.g. in Bocadillo:
Coming back at aiodine after a few months off, the initial design and API don't seem as optimal as they could be from a developer experience point of view.
The most serious problems I see are:
@consumer
modifies the signature of its decorated function (Consumer API and signature modification #23)The path that FastAPI took for its dependency injection mechanism seems to solve both of these problems. I'm curious at whether we could replicate the design here, although that should probably mean aiodine is spun up as a different library altogether (code-named
asyncdeps
below).We should make sure
depends
works well with static type checkers, e.g. by casting its return value to the return value type of its function.If we go for this style, there's one question to tackle: can we keep scopes with this API?
My intuition is that we can keep the idea of caching dependencies for reuse (which is what the "session" scope is all about), but propose a more straight-forward API.
The default behavior would be to evaluate dependencies on every call (equivalent of the current "function" scope). The behavior of the "session" scope could be obtained via an
@cached
marker, e.g.:Besides, we can force-turn on/off caching on callees, e.g.
depends(get_hello, cached=False)
.Combined with a generator-based API, this would allow us to support the database provisioning use case for async web frameworks, e.g. in Bocadillo:
Overall, I think this API would greatly reduce the scope and footprint of this library, as well as result in much simpler usage patterns for users.
I may sketch out a PoC for async-only dependencies (w/o generator support) to see how this could look like.
The text was updated successfully, but these errors were encountered: