Skip to main content

​
App erstellen

Zwei Möglichkeiten:
  • KI fragen - beschreiben Sie, was Sie möchten, in einem Thread und die KI erstellt es
  • Neue-App-Schaltfläche - klicken Sie auf + in der Drive-Seitenleiste und wählen Sie Neue App
Die KI wählt eine Startvorlage basierend auf Ihrer Anfrage:

​
Eine App, ein Branch

Jede App ist ein einzelnes Git-Checkout auf main. Es gibt keine separaten Entwürfe, kein Branch-Wechseln, keinen Merge-Schritt. Jede Bearbeitung landet auf main als Commit; Veröffentlichung bedeutet nur „das aktuelle main bereitstellen”.

​
Der Build-Zyklus

  1. Die KI schreibt Code direkt auf main
  2. Die KI startet den Dev-Server. Sie sehen eine Live-Vorschau.
  3. Sie iterieren per Chat: „verschieben Sie das Diagramm in die Seitenleiste”, „fügen Sie ein dunkles Design hinzu”
  4. Der Dev-Server lädt nach jeder Bearbeitung neu
  5. Wenn fertig, veröffentlichen

​
Veröffentlichung

Die Veröffentlichung stellt den aktuellen main-Commit bereit. Es gibt keinen separaten Production-Branch — der zuletzt veröffentlichte Commit auf main ist live. Wenn Sie im Katalog veröffentlichen, damit andere Ihre App installieren können, erhält Ihre App beim Start ein Benutzeridentitäts-Token, einen Installationsschlüssel für sein Backend und Install-/Uninstall-Webhooks. Siehe Veröffentlichung.

​
Caching, Updates und Offline

Desktop und Mobile öffnen Ihre App-URL nur in einer normalen Browser-Ansicht. Sie löschen nicht Browser-Caches, erzwingen keine Nur-Netzwerk-Ladevorgänge und wählen keine andere Cache-Richtlinie für öffentliche vs. private Apps. Ihre Web-App verwaltet das Caching:
  • HTTP-Cache-Control-Header für Dokumente und Assets
  • Optionales Service-Worker-/PWA-Setup (Vorlagen enthalten vite-plugin-pwa mit automatischem Update)
  • Ob ein neuer Build sofort aktiviert wird, einmal neu geladen wird oder auf die nächste Öffnung wartet
  • Offline-Fallback für den zuletzt aktivierten Build
Wenn Kazzle eine neue veröffentlichte Version für einen offenen App-Tab sieht, fordert es den registrierten Service Worker auf, auf ein Update zu prüfen (registration.update()). Apps ohne Service Worker ignorieren diese Prüfung und verwenden weiterhin ihre eigenen HTTP-Cache-Header. Veröffentlichte Apps können daher sofort aus dem Cache geöffnet werden, einen neuen Build ohne Hard-Refresh abrufen und den neuesten Build offline verfügbar halten.

​
Bereitstellen

Nach der Veröffentlichung bereitstellen, um eine Live-URL zu erhalten:
  • Remote-Apps werden in Kazzles Cloud bereitgestellt und erhalten eine öffentliche URL
  • Lokale Apps werden auf Ihrem Computer installiert. Die UI wird direkt geladen und der Process-Teil führt einen Dev-Server aus.

​
Echtzeit-Apps

Für Apps, die sofortige lokale Lesevorgänge und Offline-Unterstützung benötigen, erstellt die KI:
  1. Eine Datenbank
  2. Aktiviert Echtzeit-Synchronisierung
  3. Erstellt eine zweiteilige App: UI (React + Sync-Client) und Process (Token-Endpunkt + Sync-Upload)
  4. Verbindet Anmeldedaten über den Vault
Siehe Echtzeit-Synchronisierung für weitere Informationen.

​
Landing Pages

Landing Pages sind reine UI-Apps. Kein Backend, keine Datenbank. Beschreiben Sie die Seite und die KI erstellt sie, stellt sie bereit und gibt Ihnen eine Live-URL. Um eine benutzerdefinierte Domain zu verwenden, verweisen Sie Ihre Domain oder Subdomain auf die bereitgestellte App-URL.