Skip to main content

Creazione di un’app

Due modi:
  • Chiedi all’AI - descrivi quello che vuoi in una conversazione e l’AI lo crea
  • Pulsante Nuova app - fai clic su + nella barra laterale Drive e scegli Nuova app
L’AI sceglie un template iniziale in base a quello che chiedi:

Un’app, un ramo

Ogni app è un singolo checkout git su main. Non ci sono bozze separate, nessun cambio di ramo, nessun passaggio di merge. Ogni modifica finisce su main come commit; la pubblicazione è semplicemente “distribuisci il main attuale”.

Il ciclo di build

  1. L’AI scrive il codice direttamente su main
  2. L’AI avvia il dev server. Vedi un’anteprima live.
  3. Iteri tramite chat: “sposta il grafico nella barra laterale”, “aggiungi un tema scuro”
  4. Il dev server ricarica a caldo dopo ogni modifica
  5. Quando sei pronto, pubblica

Pubblicazione

La pubblicazione distribuisce il commit main attuale. Non c’è un ramo di produzione separato — il commit pubblicato più di recente su main è quello live. Quando pubblichi nel catalogo affinché altri possano installare, la tua app riceve un token di identità utente al lancio, una chiave di installazione per il suo backend e webhook di installazione/disinstallazione. Vedi Pubblicazione.

Caching, aggiornamenti e offline

Desktop e mobile aprono l’URL della tua app solo in una normale visualizzazione del browser. Non cancellano le cache del browser, non forzano caricamenti solo da rete, né scelgono una politica di cache diversa per app pubbliche rispetto a private. La tua app web gestisce il caching:
  • Header HTTP Cache-Control per documenti e asset
  • Setup opzionale di service worker / PWA (i template includono vite-plugin-pwa con aggiornamento automatico)
  • Se una nuova build si attiva immediatamente, ricarica una volta, o aspetta l’apertura successiva
  • Fallback offline per l’ultima build attivata
Quando Kazzle vede una nuova versione pubblicata per una scheda app aperta, chiede al service worker registrato di verificare un aggiornamento (registration.update()). Le app senza service worker ignorano quel controllo e continuano a usare i loro header di cache HTTP. Le app pubblicate possono quindi aprirsi istantaneamente dalla cache, raccogliere una nuova build senza un hard refresh, e mantenere l’ultima build disponibile offline.

Distribuzione

Dopo la pubblicazione, distribuisci per ottenere un URL live:
  • App remote si distribuiscono nel cloud di Kazzle e ottengono un URL pubblico
  • App locali si installano sul tuo computer. L’UI si carica direttamente e la parte process esegue un dev server.

App in tempo reale

Per app che hanno bisogno di letture locali istantanee e supporto offline, l’AI:
  1. Crea un database
  2. Attiva la sincronizzazione in tempo reale
  3. Crea un’app a due parti: UI (React + client di sincronizzazione) e Process (endpoint token + caricamento sincronizzazione)
  4. Collega le credenziali attraverso il vault
Vedi Sincronizzazione in tempo reale per come funziona.

Landing page

Le landing page sono app solo UI. Nessun backend, nessun database. Descrivi la pagina e l’AI la crea, la distribuisce e ti dà un URL live. Per usare un dominio personalizzato, punta il tuo dominio o sottodominio all’URL dell’app distribuita.