FastAPI และการทำงานแบบอะซิงโครนัส

FastAPI is built for speed! It leverages Python's asynchronous features to handle many requests concurrently, especially I/O-bound tasks.

This means your API can stay responsive even when waiting for external resources like databases or other APIs.

In FastAPI, you can define two main types of endpoint functions:

• Synchronous (def): These functions block the event loop while they run. If one request takes long, others might wait.
• Asynchronous (async def): These functions can 'pause' and let other tasks run while they await an operation (like reading from a database), making your API non-blocking.

Here's a standard synchronous endpoint. While simple, if time.sleep() were a real, slow database call, it would block other requests until it completes.

Try running it and observe the delay if you try to make multiple requests quickly.

To make your endpoint non-blocking, use async def. This tells FastAPI (and Python) that this function can be suspended and resumed.

Inside an async def function, you use the await keyword to wait for other asynchronous operations to complete without blocking the entire application.

This example uses asyncio.sleep(), which is an asynchronous sleep function. Notice the await keyword before it.

This allows FastAPI to handle other requests while this one 'sleeps', making the server more responsive.

async def shines for I/O-bound operations. These are tasks that spend most of their time waiting for something else to happen, such as:

• Making requests to external APIs (e.g., httpx).
• Querying a database (e.g., asyncpg, SQLModel).
• Reading/writing files from disk.
• Network communication.

For CPU-bound tasks (heavy calculations), async def doesn't speed up the task itself, but it can help keep the server responsive.

When your FastAPI async def endpoint needs to interact with another asynchronous library (like an async HTTP client or an async database driver), you must use await.

Failing to use await will result in the awaitable object being returned directly, not its resolved result, which is usually not what you want!

Imagine fetching data from another service. An async HTTP client allows this without blocking. Here's how it conceptually looks within an async def endpoint:

We simulate network latency with asyncio.sleep to show the non-blocking nature.

FastAPI relies on an ASGI server like Uvicorn. Uvicorn is what actually runs your async def functions efficiently.

• It manages the Python event loop, which orchestrates when different asynchronous tasks get to run.
• When an await is encountered, Uvicorn can switch to another ready task, making your API highly concurrent.

This 'context switching' is what allows FastAPI to handle many requests without waiting for each one to finish entirely.

You are building a FastAPI endpoint that needs to fetch data from a slow external API (an I/O-bound task). Which of the following is the best way to define this endpoint to ensure your FastAPI application remains responsive?

We've explored how FastAPI harnesses Python's asynchronous features:

• Use async def for endpoint functions that perform I/O-bound operations.
• Use await when calling other asynchronous functions or libraries within an async def.
• This non-blocking approach, powered by Uvicorn and the event loop, allows your FastAPI application to handle many concurrent requests efficiently, leading to highly responsive APIs.

Next, we'll look at how to offload truly long-running or CPU-bound tasks to background processes!