Naar hoofdinhoud gaan

​
Hoe het werkt

Apps met realtime sync houden een lokale database op het apparaat. Lezen is instant (lokaal), schrijven wordt lokaal in de wachtrij geplaatst, en alles synchroniseert op de achtergrond met de server. 
User writes -> Local database -> Upload queue -> Server -> Postgres
                                                            |
User reads  <- Local database <- Sync replication <---------+
Het resultaat: instant lezen, geen laadspinners, en een app die blijft werken bij slechte verbindingen of offline.

​
Wat de AI instelt

Vraag de AI om een realtime app te bouwen. Het hergebruikt een geschikte actieve database als die bestaat; anders maakt het een database aan, zet de sync service aan, en bouwt een app met twee onderdelen:
  • UI - client app met lokale database, live queries en sync connector
  • Process - token endpoint, sync upload route en migration runner
Credentials worden opgeslagen in de vault. De AI verbindt database env vars met het process component via de db tool. Voordat de app als klaar wordt beschouwd, moet de database sync: ready tonen. Als sync niet klaar is, kan de app weergegeven worden, maar realtime data tussen apparaten werkt niet.

​
Vuistregels

  • Schrijf eerst lokaal. Laat sync op de achtergrond uploaden.
  • Toon lege staten, geen laadspinners, zodra lokale data bestaat.
  • Houd gebruikszichtbare staat in gesynchroniseerde tabellen zodat deze vernieuwingen en offline gebruik overleeft.
  • Groepeer gerelateerde lokale schrijfbewerkingen zodat de UI in één stap bijwerkt.
  • Controleer sync gezondheid voordat je een realtime app klaar noemt.

​
Offline app shell

UI templates kunnen een offline app shell bevatten zodat de app na het eerste bezoek zonder netwerk opnieuw kan worden geopend. De app shell is de statische HTML, JS, CSS en pictogrammen.
  • Offline shell maakt de app zonder netwerk openbaar
  • Sync houdt de app data bruikbaar terwijl offline
Samen: de app opent zonder netwerk, toont de meest recente gesynchroniseerde data, plaatst nieuwe schrijfbewerkingen in de wachtrij, en synchroniseert wanneer de verbinding terugkomt.

​
Wanneer realtime sync gebruiken

Goed geschiktOverkill
Taakbeheerders en notitie-appsStatische marketingpagina’s
SamenwerkingstoolsEenmalige formulierinzendingen
Veldapps met zwakke connectiviteitAlleen-lezen brochuresites
Alles wat instant moet voelenApps zonder offline waarde

​
Platform variabelen

Kazzle injecteert automatisch een kleine set omgevingsvariabelen in elk app process. Deze zijn gescheiden van je eigen vault secrets.
VariabeleWat het is
PORTDe poort waarop je process moet luisteren
HOSTDe hostnaam om aan te binden (meestal 0.0.0.0)
KAZZLE_API_URLBasis-URL gebruikt door Kazzle runtime helpers
KAZZLE_APP_COMPONENT_<NAME>_URLRuntime URL van een sibling component

​
Sibling URL’s

Wanneer een app meerdere components heeft (bijv. een web UI en een server process), kan Kazzle URL’s voor sibling components injecteren: 
# In het "web" onderdeel:
KAZZLE_APP_COMPONENT_SERVER_URL=http://localhost:3001

# In het "server" onderdeel:
KAZZLE_APP_COMPONENT_WEB_URL=http://localhost:3000
Wanneer een sibling al is geïmplementeerd, wijst de geïnjecteerde waarde naar dat geïmplementeerde component. Anders wijst het naar het huidige development adres voor dat sibling.