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
i actually started investigating it in a branch somewhere once but i didn't finish it.
the tricky bit is figuring out how far down the stack you are going to allow async/await to encroach. the pure domain code needs to be non-async, i would say. but what about the Repository and the UnitOfWork? Or the Service Layer? i didn't decide on a final answer for that...
Theoretically it should be possible based on my understanding, it looks like the repository, service layer handlers to the entry points will be async and external calls awaited. Will investigate this further and document my findings here.
Thanks for making efforts in this direction will definitely be on the look out to see how you implement this including the message_bus as async. Thank you for sharing.
Thanks for making efforts in this direction will definitely be on the look out to see how you implement this including the message_bus as async. Thank you for sharing.
I am not sure. If I understood it right the problem is when you have a server that don't spin up one thread per request. The reason been that the bus is a module variable and when in the same thread that would be a problem for the bus queue and the db session, since multiple requests would share the queue and session. In my case I am creating a new queue and uow on a per request basis, but I guess this is a problem for the tests on the project. I don't really know, because I am not running the projects code/tests.
if i get a bit more time, i want to investigate some more patterns around this. can we make it so that the repository is non-async somehow?? if you could somehow pre-load the state before entering the service layer, and have the outputs be some combination of state to modify (on a sqla session maybe?) plus events, then maybe the whole service layer could be sync somehow? it wouldn't work for the UoW, but, idk, the dream is, the fewer unit tests use async, the better.
async tests are slower (they tend to start and stop an event loop, makes them an order of magnitude slower in my experience)
(i haven't really thought this through or experimented with it enough but) i see async as a sort of marker for "here be side effects + IO", so i thought of it as a really nice way of separating out a "functional core" from an "imperative shell", in the actual syntax of the language - a bit like the IO Monad in haskell. so in the python world, i'm thinking that the challenge is to keep as much of the core logic (and its unit tests) in a non-async world, and keep the async as close to the edges as possible. but that may not be compatible with repository pattern and unit of work.
Activity
hjwp commentedon Mar 20, 2023
i actually started investigating it in a branch somewhere once but i didn't finish it.
the tricky bit is figuring out how far down the stack you are going to allow async/await to encroach. the pure domain code needs to be non-async, i would say. but what about the Repository and the UnitOfWork? Or the Service Layer? i didn't decide on a final answer for that...
Didza commentedon Mar 20, 2023
Theoretically it should be possible based on my understanding, it looks like the repository, service layer handlers to the entry points will be async and external calls awaited. Will investigate this further and document my findings here.
nomhoi commentedon Mar 30, 2023
Please see my refactoring: https://github.com/nomhoi/cosmicpython-fastapi
nomhoi commentedon Mar 30, 2023
There are many examples with asynchronous FastAPI for RealWorld project:
https://github.com/search?q=realworld+fastapi
Didza commentedon Mar 30, 2023
Thanks for making efforts in this direction will definitely be on the look out to see how you implement this including the message_bus as async. Thank you for sharing.
nomhoi commentedon Mar 31, 2023
I intend to complete all chapters.
jalvespinto commentedon Apr 4, 2023
@nomhoi, tks for sharing this. While you are at it, it would be nice to consider issue #23
nomhoi commentedon Apr 5, 2023
Ok, a bit later.
nomhoi commentedon Apr 11, 2023
All 13 chapters have been completed.
nomhoi commentedon Apr 11, 2023
Is the problem in this test?
https://github.com/xtaje/code/blob/2f260cba7eae3c6467c14befddfa92cc6d003c52/tests/e2e/test_queue_race.py
jalvespinto commentedon Apr 15, 2023
I am not sure. If I understood it right the problem is when you have a server that don't spin up one thread per request. The reason been that the
busis a module variable and when in the same thread that would be a problem for the bus queue and the db session, since multiple requests would share the queue and session. In my case I am creating a new queue and uow on a per request basis, but I guess this is a problem for the tests on the project. I don't really know, because I am not running the projects code/tests.hjwp commentedon Apr 26, 2023
this is awesome! well done :)
if i get a bit more time, i want to investigate some more patterns around this. can we make it so that the repository is non-async somehow?? if you could somehow pre-load the state before entering the service layer, and have the outputs be some combination of state to modify (on a sqla session maybe?) plus events, then maybe the whole service layer could be sync somehow? it wouldn't work for the UoW, but, idk, the dream is, the fewer unit tests use async, the better.
jalvespinto commentedon Apr 26, 2023
@hjwp why do you want a non-async? I am asking just because I am going full async on a project that I use the archit from your book.
hjwp commentedon Apr 27, 2023
two reasons at the top of my mind:
nomhoi commentedon May 16, 2023
I used in conftest.py:
Only one event loop will be created per a testing session:
https://pytest-asyncio.readthedocs.io/en/latest/reference/fixtures.html#event-loop
By default the scope is 'function'.
nomhoi commentedon May 16, 2023
May be this will be usefull: https://returns.readthedocs.io/en/latest/pages/future.html
dbaber commentedon Sep 7, 2023
Are derivatives/forks like the Fastapi one even legally allowed on github because the license is CC-By-ND?
hjwp commentedon Sep 25, 2023
for the record, it's fine by me. i'll see what i can do about the license...