Realtime
Poussez les changements vers vos clients connectés au lieu de les interroger en boucle : un flux WebSocket par canal, authentifié par la session de l’utilisateur.
Suivre les changements de la base
Un abonnement « postgres_changes » reçoit les insertions, mises à jour et suppressions d’une table. Filtrez sur le schéma et la table, et sur un type d’événement précis si votre écran n’a pas besoin du reste.
JavaScript
import { createClient } from '@kuunda/kuunda-js';
const kuunda = createClient(process.env.NEXT_PUBLIC_KUUNDA_URL!, process.env.NEXT_PUBLIC_KUUNDA_ANON_KEY!);
const canal = kuunda
.channel('realtime:mes_taches')
.on('postgres_changes', { event: '*', schema: 'public', table: 'mes_taches' }, (payload) => {
// payload.eventType vaut INSERT, UPDATE ou DELETE
console.log(payload.eventType, payload.new ?? payload.old);
})
.on('broadcast', { event: 'presence' }, (message) => {
console.log(message.payload);
});
await canal.subscribe();Le canal se souscrit une fois et se ferme quand l’écran est démonté.
Diffuser vos propres messages
Un abonnement « broadcast » transporte vos événements applicatifs — présence, progression, notifications — sur un canal nommé. C’est le bon outil pour ce qui ne vient pas de la base.
Sécurité
Le canal applique les mêmes politiques que le reste : un client n’obtient que les lignes qu’il a le droit de lire. La connexion s’authentifie avec la session de l’utilisateur, ou avec la clé anonyme pour un accès public.
- Ne diffusez jamais de données sensibles sur un canal public : tous les clients abonnés les reçoivent.
- La clé de service est réservée au serveur, y compris pour Realtime.
Disponibilité
Si le service ne répond pas, les abonnements échouent et la console le signale : prévoyez un repli (rafraîchissement périodique) pour les écrans critiques. Le sandbox ne fournit pas Realtime.