Que sont les Live Queries en temps réel ?

Une live query est un abonnement à une requête de base de données : le serveur pousse les événements create, update et delete des lignes correspondantes. C’est le temps verbal qui manquait à l’accès aux données : les requêtes normales parlent au passé (« ce qui correspondait quand j’ai demandé »), les live queries parlent au présent continu (« ce qui correspond, au fur et à mesure que ça change »). L’écran cesse de demander et se met à rester à jour.

Points clés

L’abonnement, en code

Le geste qui définit tout — prenez la requête que vous aviez déjà, et abonnez-vous à elle :

// JavaScript / Node.js — Back4app JS SDK
// A live query: subscribe to a QUERY and receive its changes as events
const query = new Parse.Query('Task');
query.equalTo('assignee', currentUser);

const sub = await query.subscribe();
sub.on('create', (t) => addRow(t));       // new match appeared
sub.on('update', (t) => refreshRow(t));   // a match changed
sub.on('enter',  (t) => addRow(t));       // edited INTO the result set
sub.on('leave',  (t) => removeRow(t));    // edited OUT of the result set
sub.on('delete', (t) => removeRow(t));    // a match was deleted

// Flutter / Dart — Back4app Flutter SDK
// A live query: subscribe to a QUERY and receive its changes as events
final liveQuery = LiveQuery();
final query = QueryBuilder<ParseObject>(ParseObject('Task'))
  ..whereEqualTo('assignee', currentUser);

final sub = await liveQuery.client.subscribe(query);
sub.on(LiveQueryEvent.create, (t) => addRow(t));     // new match
sub.on(LiveQueryEvent.update, (t) => refreshRow(t)); // match changed
sub.on(LiveQueryEvent.enter, (t) => addRow(t));      // edited into the set
sub.on(LiveQueryEvent.leave, (t) => removeRow(t));   // edited out of the set

// iOS / Swift — Back4app Swift SDK
// A live query: subscribe to a QUERY and receive its changes as events
let query = Task.query("assignee" == currentUser)

let subscription = query.subscribeCallback
subscription?.handleEvent { _, event in
  switch event {
  case .created(let t):  addRow(t)        // new match appeared
  case .updated(let t):  refreshRow(t)    // a match changed
  case .entered(let t):  addRow(t)        // edited INTO the result set
  case .left(let t):     removeRow(t)     // edited OUT of the result set
  case .deleted(let t):  removeRow(t)
  }
}

// Android / Kotlin — Back4app Android SDK
// A live query: subscribe to a QUERY and receive its changes as events
val client = ParseLiveQueryClient.Factory.getClient()
val query = ParseQuery.getQuery<ParseObject>("Task")
query.whereEqualTo("assignee", currentUser)

val sub = client.subscribe(query)
sub.handleEvent(SubscriptionHandling.Event.CREATE) { _, t -> addRow(t) }
sub.handleEvent(SubscriptionHandling.Event.UPDATE) { _, t -> refreshRow(t) }
sub.handleEvent(SubscriptionHandling.Event.ENTER)  { _, t -> addRow(t) }
sub.handleEvent(SubscriptionHandling.Event.LEAVE)  { _, t -> removeRow(t) }

Le vocabulaire des événements mérite son tableau, car enter et leave sont ce qui fait de ceci un abonnement à une requête plutôt qu’une notification de table :

Le pipeline derrière le push

Deux moitiés, proprement séparables : la source de changements — le flux d’écritures de la base de données elle-même (change streams dans les stores documentaires, logs de réplication ailleurs) — et la couche de matching, qui confronte chaque changement à chaque prédicat enregistré et pousse vers exactement les abonnés dont les résultats ont changé, permissions appliquées par abonné. Le protocole ouvert LiveQuery est une implémentation de référence lisible de toute cette forme.

Live queries vs. polling vs. SSE vs. WebSockets

La dernière colonne est l’argument : avec des sockets bruts vous construisez le protocole de messages, le routage, les vérifications de permissions et le rattrapage après reconnexion ; avec les live queries, le prédicat est le protocole et la plateforme possède le reste.

Cas d’usage courants

• Chat et boîtes de réception — abonnez-vous aux messages de la conversation ; l’arrivée est un événement, pas un rafraîchissement.
• Dashboards en direct — commandes, métriques, flottes : la requête définit la vue, les événements la maintiennent vraie.
• Applications collaboratives — tableaux de tâches et documents partagés où les modifications de cinq personnes s’entremêlent en quelques secondes.
• Présence et statut — qui est en ligne, ce qui est en cours — enter/leave font là leur travail de précision.
• Écrans opérationnels — consoles de support et vues d’administration qui doivent refléter la production maintenant, pas au dernier rafraîchissement.

Poller, pousser ou s’abonner ? Matrice de décision

La discipline côté client qui garde les abonnements en bonne santé, quel que soit votre choix : abonnez-vous étroitement (des prédicats sélectifs sur des champs indexés), et désabonnez-vous quand l’écran se ferme — les requêtes permanentes sont de l’état serveur, et les écrans qui les laissent fuir accumulent un coût invisible.

Limites et trade-offs

• Le matching est une vraie charge de travail. Chaque écriture est confrontée aux prédicats enregistrés ; des milliers d’abonnements larges sur des classes très sollicitées le multiplient — la sélectivité est le levier.
• Les connexions sont de l’état. La flotte de sockets a besoin d’affinité, de heartbeats et de backplanes de fan-out — les plateformes gérées existent précisément parce que c’est du travail lourd et indifférencié.
• Les reconnexions exigent un rattrapage. Un client qui était hors ligne a manqué des événements ; les flux robustes ré-exécutent la requête de base au réabonnement au lieu de supposer que rien ne s’est passé pendant la coupure.
• L’ordre et la livraison relèvent de l’at-least-once. Des handlers d’événements idempotents (appliquer par ID d’objet, pas par ajout) absorbent élégamment le doublon occasionnel.
• Tout ne réclame pas un abonnement. Des données rarement consultées et rarement modifiées sont le territoire du polling ; les live queries méritent leur coût là où les regards et les écritures sont tous deux fréquents.

Live queries sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Live Query en est la couche temps réel, et les onglets de code ci-dessus sont toute l’histoire côté client : le même query builder que vous utilisez déjà, un seul appel d’abonnement, cinq événements typés — avec des ACL vérifiées par abonné pour que le temps réel ne contourne jamais le modèle de permissions, et la flotte de WebSockets, les change streams et le fan-out qui tournent comme une infrastructure gérée. Activez Live Query sur une classe dans le dashboard, abonnez-vous depuis n’importe quel SDK, et le présent continu devient une fonctionnalité, pas un projet.