Zum Hauptinhalt springen

​
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. 
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 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-AppsStatische Marketing-Seiten
Kollaborative ToolsEinmalige Formular-Übermittlungen
Field-Apps mit schwacher KonnektivitätSchreibgeschützte Broschüren-Websites
Alles, das sich sofort anfühlen sollteApps ohne Offline-Nutzen

​
Plattformvariablen

Kazzle injiziert automatisch einen kleinen Satz von Umgebungsvariablen in jeden App-Process. Diese sind getrennt von Ihren eigenen Vault-Secrets.
VariableWas es ist
PORTDer Port, auf dem Ihr Process lauschen sollte
HOSTDer Hostname zum Binden (typischerweise 0.0.0.0)
KAZZLE_API_URLBasis-URL, die von Kazzle-Runtime-Helfern verwendet wird
KAZZLE_APP_COMPONENT_<NAME>_URLRuntime-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.