كيف يعمل BackgroundTasks؟

Question

Accepted Answer

يتيح **`BackgroundTasks`** في FastAPI تشغيل العمل **بعد إرجاع الاستجابة** — بحيث يحصل العميل على رد سريع بينما يحدث العمل الإضافي الخفيف (إرسال بريد إلكتروني، تسجيل، تنظيف) في الخلفية. إنها مدمجة وبسيطة، للمهام الخفيفة الوزن.

## استخدام BackgroundTasks

```python
from fastapi import BackgroundTasks

def send_email(address: str, message: str):
    # slow-ish work that the client shouldn't wait for
    email_client.send(address, message)

@app.post("/signup")
def signup(user: User, background_tasks: BackgroundTasks):   # inject BackgroundTasks
    save_user(user)
    background_tasks.add_task(send_email, user.email, "Welcome!")   # queue it
    return {"message": "User created"}    # RESPONSE returns NOW; email sends AFTER
```

قم بحقن معامل `BackgroundTasks` واستدع `add_task(func, *args)`. يرسل FastAPI الاستجابة أولاً، ثم يشغل المهمة(المهام) المُدرجة في قائمة الانتظار — بحيث لا ينتظر المستخدم البريد الإلكتروني.

## مهام متعددة والاستخدام مع التبعيات

```python
@app.post("/order")
def create_order(order: Order, bg: BackgroundTasks):
    bg.add_task(send_confirmation, order.email)
    bg.add_task(update_analytics, order.id)     # multiple tasks run in order, after the response
    return {"status": "created"}
```

## القيد الحاسم: إنها ليست للعمل الثقيل/الحرج

```text
BackgroundTasks runs IN THE SAME PROCESS as the web server:
  ✗ NO persistence — if the server crashes/restarts, queued tasks are LOST
  ✗ NO retries, scheduling, or distribution
  ✗ Heavy CPU work would still tie up the worker process
→ Good for: quick, non-critical, fire-and-forget tasks (emails, logging, light cleanup)
→ For heavy, critical, retryable, or scheduled jobs → use Celery / ARQ (a real task queue)
```

## متى تستخدم أيها

```text
BackgroundTasks → simple, lightweight, best-effort work tied to a request (no extra infra)
Celery / ARQ    → durable, retryable, scheduled, distributed jobs (needs a broker/workers)
```

## لماذا يهم

`BackgroundTasks` هي أداة مدمجة مريحة للحاجة الشائعة للقيام بعمل إضافي دون جعل العميل ينتظر — إرسال بريد ترحيب، كتابة سجل، تنظيف خفيف — مما يحسّن أوقات الاستجابة للمستخدم.

فهمها مفيد لهذه الحالات الخفيفة اليومية لأنها لا تتطلب بنية تحتية إضافية.

لكن **النقطة الأهم** هي معرفة **قيودها**: لأنها تعمل في نفس عملية خادم الويب، فهي لا توفر استمرارية (تُفقد المهام عند التعطل/إعادة التشغيل)، ولا إعادة محاولة، ولا جدولة، وليست مناسبة للعمل الثقيل أو الحرج.

الاعتراف بهذا الحد — استخدام `BackgroundTasks` للمهام السريعة وغير الحرجة والمطلقة وعدم متابعتها، وطابور مهام حقيقي مثل **Celery/ARQ** للمهام الخلفية الدائمة والقابلة لإعادة المحاولة والمجدولة أو الثقيلة — هو الحكم الرئيسي الذي يمنع الخطأ الشائع بالاعتماد على BackgroundTasks للعمل الذي يجب عدم فقدانه، مما يجعل هذه معرفة عملية مهمة لبناء تطبيقات موثوقة.