Clarification regarding a point mentioned in FastAPI's Async Documentation #10771
-
First Check
Commit to Help
Example CodeNoneDescriptionInside the FastAPI's Async Documentation there is a point that states:
Now after reading through this entire page I think that the recommended choice for the above mentioned point should be I am aware that this might be an insignificant thing to open a discussion for but I would greatly appreciate if someone could clarify this. Thank you for your time. P.S. Apologies for any mistakes regarding the formatting or structure of this post. Operating SystemWindows Operating System DetailsNo response FastAPI VersionNone Pydantic VersionNone Python VersionNone Additional ContextNo response |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
FastAPI is an async framework, and async should the be the default choice. Really the threadpool def endpoints are an escape hatch for running sync/blocking code because the python async ecosystem is still pretty nascent (and sometimes you just need to run blocking code). There is also the problem of function coloring. You cannot as easily run an async function ( which should be the majority of your functions) inside a def function. You also take a performance hit spawning the request to a thread pool. Anyway I agree that the docs there are worded a bit awkwardly and should probably say something like "If you don't have any blocking IO or CPU bound code you should use async" but they are supposed to be high level and it gets into it more down the page. |
Beta Was this translation helpful? Give feedback.
FastAPI is an async framework, and async should the be the default choice.
Really the threadpool def endpoints are an escape hatch for running sync/blocking code because the python async ecosystem is still pretty nascent (and sometimes you just need to run blocking code).
There is also the problem of function coloring. You cannot as easily run an async function ( which should be the majority of your functions) inside a def function.
You also take a performance hit spawning the request to a thread pool.
Anyway I agree that the docs there are worded a bit awkwardly and should probably say something like "If you don't have any blocking IO or CPU bound code you should use async" but they are …