FastAPI ஏன் வேகமானது, மேலும் அதை எவ்வாறு அப்படியே வைத்திருப்பது?

Question

Accepted Answer

FastAPI மிக வேகமான Python frameworks-இல் ஒன்றாகும், ஏனெனில் இது **Starlette**-இல் (ஒரு lightweight ASGI framework) கட்டப்பட்டுள்ளது மற்றும் **async-native**-ஆகும், பல concurrent I/O-bound requests-ஐ திறமையாகக் கையாளுகிறது. ஆனால் அதை வேகமாக வைத்திருப்பது async-ஐ சரியாகப் பயன்படுத்துவது தேவைப்படுகிறது — மிகவும் பொதுவான தவறு event loop-ஐ block செய்வது.

## இது ஏன் வேகமானது

```text
✓ ASGI + Starlette — a modern async foundation (vs older WSGI sync frameworks)
✓ Async-native — one process handles thousands of concurrent I/O-bound requests
  by overlapping wait times, instead of one-at-a-time
✓ Pydantic v2 — validation/serialization core is now in Rust (very fast)
✓ Minimal overhead per request
```

async model முக்கியம்: ஒரு request ஒரு database query அல்லது API call-க்காகக் காத்திருக்கும்போது, server மற்றவற்றைக் கையாளுகிறது — I/O-bound workloads-க்கு உயர் throughput-ஐக் கொடுக்கிறது.

## அதை வேகமாக வைத்திருக்கும் #1 வழி: event loop-ஐ block செய்யாதீர்கள்

```python
# ❌ blocking call inside async def → freezes the event loop, serializing ALL requests
@app.get("/bad")
async def bad():
    return requests.get(url).json()       # SYNC/blocking → kills concurrency

# ✅ use an async client and await it
@app.get("/good")
async def good():
    async with httpx.AsyncClient() as c:
        return (await c.get(url)).json()  # non-blocking

# ✅ OR use a plain def — FastAPI runs it in a thread pool (safe for blocking code)
@app.get("/also-good")
def also_good():
    return requests.get(url).json()
```

இது மிக முக்கியமான ஒற்றை performance விதி: `async def`-க்குள் ஒரு blocking call முழு event loop-ஐயும் block செய்கிறது, requests-ஐ ஒவ்வொன்றாக இயங்கச் செய்கிறது. async libraries-ஐ `await`-உடன், அல்லது ஒரு plain `def`-ஐ (thread pool-இல் இயக்கப்படுகிறது) பயன்படுத்துங்கள்.

## அதை வேகமாக வைத்திருத்தல் — checklist

```text
✓ Use async DB drivers / async libraries (httpx, asyncpg) in async endpoints
✓ Run blocking code in plain def (thread pool) or via run_in_executor
✓ Avoid heavy CPU work on the event loop → offload to workers/processes
✓ Add caching (Redis) for expensive repeated work
✓ Optimize the database (fix N+1, add indexes) — often the real bottleneck
✓ Run multiple worker processes (uvicorn/gunicorn workers) to use all CPU cores
✓ Use connection pooling; paginate large results
✓ MEASURE first (profiling, load testing) — fix the actual bottleneck
```

## இது ஏன் முக்கியம்

FastAPI-இன் வேகம் teams அதைத் தேர்ந்தெடுப்பதற்கான ஒரு முதன்மை காரணம், ஆனால் நடைமுறையில் அந்த வேகத்தை அடைவது **async-ஐ சரியாகப் பயன்படுத்துவதைச்** சார்ந்துள்ளது — மேலும் மிக முக்கியமான, அடிக்கடி மீறப்படும் விதி **event loop-ஐ ஒருபோதும் block செய்யாதது** ஆகும்.

FastAPI ஏன் வேகமானது என்பதைப் புரிந்துகொள்வது (async-native ASGI foundation, திறமையான I/O concurrency, வேகமான Pydantic v2 core) அதன் performance edge concurrent-ஆகக் கையாளப்படும் I/O-bound workloads-க்குப் பொருந்தும் என்பதைத் தெளிவுபடுத்துகிறது.

அதை வேகமாக *வைத்திருப்பது* எப்படி என்பதை அறிந்திருப்பது முக்கியமான நடைமுறைத் திறன்: `async def`-இல் blocking calls வைக்கும் பேரழிவு தவறைத் தவிர்ப்பது (இது எல்லா requests-ஐயும் ஒரு freeze ஆன event loop-க்குப் பின்னால் serialize செய்கிறது), async endpoints-இல் async libraries-ஐப் பயன்படுத்துவது (அல்லது blocking code-க்கு plain `def`), CPU work-ஐ offload செய்வது, caching, database-ஐ optimize செய்வது (பெரும்பாலும் உண்மையான bottleneck), மற்றும் பல cores-க்காக பல workers-ஐ இயக்குவது.

இந்தக் கலவை — async-ஐ சரியாகப் பயன்படுத்துவது மற்றும் உண்மையான bottlenecks-ஐக் கண்டறிய measure செய்வது — FastAPI-இன் performance திறனை உணர உங்களை அனுமதிக்கிறது, இது async போல தோற்றமளித்து blocking code போல செயல்படும் ones-க்குப் பதிலாக உண்மையிலேயே வேகமான, scalable APIs-ஐ உருவாக்குவதற்கான முக்கியமான senior-level அறிவாக ஆக்குகிறது.