> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kazzle.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Echtzeit-Synchronisierung

> Lokal-erste Apps mit Offline-Unterstützung und automatischer Hintergrund-Synchronisierung.

## So funktioniert es

Apps mit Echtzeit-Synchronisierung speichern eine lokale Datenbank auf dem Gerät. Lesevorgänge sind sofort (lokal), Schreibvorgänge werden lokal in die Warteschlange eingereiht, und alles wird im Hintergrund mit dem Server synchronisiert.

```text theme={"theme":"material-theme-darker"}
Benutzer schreibt -> Lokale Datenbank -> Upload-Warteschlange -> Server -> Postgres
                                                                            |
Benutzer liest   <- Lokale Datenbank <- Sync-Replikation <-----------------+
```

Das Ergebnis: sofortige Lesevorgänge, keine Lade-Spinner und eine App, die auch bei schlechten Verbindungen oder offline funktioniert.

## Was die KI einrichtet

Bitten Sie die KI, eine Echtzeit-App zu erstellen. Sie nutzt eine geeignete aktive Datenbank, falls vorhanden; andernfalls erstellt sie eine Datenbank, aktiviert den Sync-Service und erstellt eine zweiteilige App:

* **UI** - Client-App mit lokaler Datenbank, Live-Abfragen und Sync-Connector
* **Process** - Token-Endpunkt, Sync-Upload-Route und Migrations-Runner

Anmeldedaten werden im [Vault](/work/vault) gespeichert. Die KI verbindet Datenbank-Umgebungsvariablen mit der Process-Komponente über das `db`-Tool.

Bevor die App als bereit gilt, muss die Datenbank `sync: ready` anzeigen. Wenn Sync nicht bereit ist, kann die App zwar rendern, aber geräteübergreifende Echtzeit-Daten funktionieren nicht.

## Faustregeln

* Schreiben Sie zuerst lokal. Lassen Sie Sync im Hintergrund hochladen.
* Zeigen Sie leere Zustände an, keine Lade-Spinner, sobald lokale Daten vorhanden sind.
* Halten Sie sichtbare Benutzerzustände in synchronisierten Tabellen, damit sie Aktualisierungen und Offline-Nutzung überstehen.
* Gruppieren Sie zusammenhängende lokale Schreibvorgänge, damit die UI als ein Schritt aktualisiert wird.
* Überprüfen Sie die Sync-Integrität, bevor Sie eine Echtzeit-App als fertig betrachten.

## Offline-App-Shell

UI-Templates können eine Offline-App-Shell enthalten, damit die App nach dem ersten Besuch ohne Netzwerk erneut geöffnet werden kann. Die App-Shell ist das statische HTML, JS, CSS und die Icons.

* **Offline-Shell** ermöglicht das Öffnen der App ohne Netzwerk
* **Sync** hält die App-Daten offline nutzbar

Zusammen: Die App öffnet sich ohne Netzwerk, zeigt die neuesten synchronisierten Daten, reiht neue Schreibvorgänge in die Warteschlange ein und synchronisiert, wenn die Verbindung zurückkommt.

## Wann Echtzeit-Synchronisierung verwenden

| Gut geeignet                           | Übertrieben                           |
| -------------------------------------- | ------------------------------------- |
| Task-Manager und Notiz-Apps            | Statische Marketing-Seiten            |
| Kollaborative Tools                    | Einmalige Formular-Übermittlungen     |
| Field-Apps mit schwacher Konnektivität | Schreibgeschützte Broschüren-Websites |
| Alles, das sich sofort anfühlen sollte | Apps ohne Offline-Nutzen              |

## Plattformvariablen

Kazzle injiziert automatisch einen kleinen Satz von Umgebungsvariablen in jeden App-Process. Diese sind getrennt von Ihren eigenen [Vault-Secrets](/work/vault).

| Variable                          | Was es ist                                               |
| --------------------------------- | -------------------------------------------------------- |
| `PORT`                            | Der Port, auf dem Ihr Process lauschen sollte            |
| `HOST`                            | Der Hostname zum Binden (typischerweise `0.0.0.0`)       |
| `KAZZLE_API_URL`                  | Basis-URL, die von Kazzle-Runtime-Helfern verwendet wird |
| `KAZZLE_APP_COMPONENT_<NAME>_URL` | Runtime-URL einer Schwester-Komponente                   |

### Schwester-URLs

Wenn eine App mehrere Komponenten hat (z. B. eine `web`-UI und einen `server`-Process), kann Kazzle URLs für Schwester-Komponenten injizieren:

```
# Im "web"-Teil:
KAZZLE_APP_COMPONENT_SERVER_URL=http://localhost:3001

# Im "server"-Teil:
KAZZLE_APP_COMPONENT_WEB_URL=http://localhost:3000
```

Wenn eine Schwester-Komponente bereits bereitgestellt ist, verweist der injizierte Wert auf diese bereitgestellte Komponente. Andernfalls verweist er auf die aktuelle Entwicklungsadresse für diese Schwester-Komponente.