Wie funktioniert BackgroundTasks?

Question

Accepted Answer

FastAPI's **`BackgroundTasks`** ermöglicht es dir, Arbeit **nach dem Zurückgeben der Antwort** auszuführen — so erhält der Client eine schnelle Antwort, während leichte Folgarbeiten (E-Mail versenden, Logging, Cleanup) im Hintergrund ablaufen. Es ist eingebaut und einfach, für leichte Aufgaben.

## BackgroundTasks verwenden

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

Injiziere einen `BackgroundTasks`-Parameter und rufe `add_task(func, *args)` auf. FastAPI sendet zuerst die Antwort, führt dann die eingereihten Aufgaben aus — so muss der Benutzer nicht auf die E-Mail warten.

## Mehrere Aufgaben und Verwendung mit Abhängigkeiten

```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"}
```

## Warum es wichtig ist

`BackgroundTasks` ist ein praktisches eingebautes Tool für das alltägliche Bedürfnis, Folgeprojekte durchzuführen, ohne den Client warten zu lassen — Willkommens-E-Mail versenden, ein Protokoll schreiben, leichte Bereinigung — die Antwortzeiten für den Benutzer verbessern.

Das Verständnis dafür ist für diese alltäglichen Lightweight-Fälle nützlich, da es keine zusätzliche Infrastruktur erfordert.

Aber **der wichtigste Punkt** ist das Verständnis ihrer **Einschränkungen**: Da sie im gleichen Prozess wie der Webserver läuft, bietet sie keine Persistierung (Aufgaben gehen bei Absturz/Neustart verloren), keine Wiederholungen, keine Planung und ist nicht für schwere oder kritische Arbeit geeignet.

Diese Grenze zu erkennen — die Verwendung von `BackgroundTasks` für schnelle, unkritische, "Fire-and-Forget"-Aufgaben und eine echte Task-Queue wie **Celery/ARQ** für dauerhafte, wiederholbare, geplante oder schwere Hintergrundaufträge — ist die Schlüsselbewertung, die den häufigen Fehler verhindert, sich bei Arbeiten, die nicht verloren gehen dürfen, auf BackgroundTasks zu verlassen, was dieses wichtige praktische Wissen zum Erstellen zuverlässiger Anwendungen macht.

## Das entscheidende Einschränkung: Es ist NICHT für schwere/kritische Arbeit

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

## Wann sollte man welches verwenden

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