لماذا يكون FastAPI سريعاً، وكيف تحافظ على سرعته؟

Question

Accepted Answer

FastAPI هو من بين أسرع أطر عمل Python لأنه مبني على **Starlette** (إطار عمل ASGI خفيف الوزن) وهو **async-native**، مما يتعامل بكفاءة مع العديد من طلبات I/O-bound المتزامنة. لكن الحفاظ على السرعة يتطلب استخدام async بشكل صحيح — الخطأ الأكثر شيوعاً هو حجب حلقة الأحداث.

## لماذا يكون سريعاً

```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 هو المفتاح: بينما ينتظر أحد الطلبات استعلام قاعدة البيانات أو استدعاء API، يتعامل الخادم مع طلبات أخرى — مما يعطي throughput عالياً لأعباء العمل I/O-bound.

## الطريقة الأولى للحفاظ على السرعة: لا تحجب حلقة الأحداث

```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()
```

هذه هي قاعدة الأداء الأكثر أهمية: استدعاء حجب داخل `async def` يحجب حلقة الأحداث بأكملها، مما يفرض على الطلبات أن تعمل واحداً تلو الآخر. استخدم مكتبات async مع `await`، أو `def` عادياً (يعمل في thread pool).

## الحفاظ على السرعة — قائمة التحقق

```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 هي السبب الأساسي الذي يختار الفرق استخدامه، لكن تحقيق تلك السرعة في الممارسة يعتمد على **استخدام async بشكل صحيح** — والقاعدة الأكثر أهمية والمنتهكة بشكل متكرر هي **عدم حجب حلقة الأحداث أبداً**.

فهم *السبب* في أن FastAPI سريع (أساس ASGI async-native، كفاءة التزامن I/O، Pydantic v2 core السريع) يوضح أن ميزة الأداء الخاصة به تنطبق على أعباء عمل I/O-bound التي يتم التعامل معها بالتزامن.

معرفة كيفية *الحفاظ* على سرعته هي المهارة العملية الحاسمة: تجنب الخطأ المدمر المتمثل في وضع استدعاءات حجب في `async def` (الذي يسلسل جميع الطلبات خلف حلقة أحداث متجمدة)، استخدام مكتبات async في نقاط نهاية async (`async endpoints`) (أو `def` عادياً للكود الحجب)، نقل عمل CPU، caching، تحسين قاعدة البيانات (غالباً الاختناق الحقيقي)، وتشغيل عمال متعددين لأنوية متعددة.

هذا المزيج — الاستفادة من async بشكل صحيح والقياس للعثور على اختناقات حقيقية — هو ما يسمح لك بإدراك إمكانات أداء FastAPI، مما يجعله معرفة على مستوى كبير مهمة لبناء APIs سريعة وقابلة للتوسع حقاً بدلاً من تلك التي تبدو async لكنها تؤدي مثل الكود الحجب.