Réplique grande image

Réplique

Il s'agit d'un cadre qui permet de mettre en œuvre Local First Software. Git aide également à organiser des tâches synchronisées via push et pull.

Replicache synchronise les données du serveur de manière asynchrone en arrière-plan, éliminant ainsi les allers-retours du serveur et permettant des modifications immédiates de l'interface utilisateur.

Pièces de réplique

Replicache se compose de plusieurs éléments.

Réplique

Replicache peut être considéré comme un magasin de valeurs-clés dans le navigateur qui inclut des opérations de type git en interne. Écrivez d'abord dans la mémoire et synchronisez plus tard.

Votre candidature

Il s'agit d'une application que nous avons créée, comme une application Web. C'est l'entité qui stocke l'état dans Replicache. Mutator et Subscription sont implémentés pour changer et répondre à l'état

.

Votre serveur

Il existe pour stocker les données les plus fiables. L'état stocké dans la base de données connectée au serveur est prioritaire sur l'état dans l'application.

Le serveur doit implémenter le push (en amont) et le pull (en aval) pour communiquer avec le Replicache du client.

• push (upstream) : Replicache envoie les modifications au point de terminaison push. Les mutateurs sont implémentés sur les serveurs ainsi que sur les applications, et ce point de terminaison push exécute ce mutateur pour modifier l'état de la base de données.

• pull (en aval) : lorsqu'il est demandé périodiquement ou explicitement, Replicache envoie une demande d'extraction au serveur. Le serveur renvoie les modifications nécessaires pour que le client devienne identique à l'état du serveur.

• poke : Bien que le client envoie périodiquement une pull request, afin de l'afficher plus en temps réel, lorsqu'il y a un changement sur le serveur, c'est un signal que le serveur donne un indice au client pour faire une pull request. Il ne contient aucune donnée.

Synchroniser

L'application et le serveur sont synchronisés avec le dernier état. L'image ci-dessous montre clairement ce processus. Il montre le processus d'extraction périodique des changements d'état du serveur et de mise à jour de l'interface utilisateur, et comment les changements d'état sur le client mettent d'abord à jour l'interface utilisateur, puis sont transmis au serveur

.

Source

Clients, groupes de clients, caches

Le réplicache en mémoire est appelé Client.

import {Replicache} from "replicache";

const rep = new Replicache({
  name: userID,
  ...
});

console.log(rep.clientID);

Il y a généralement un client par robinet. Le client est volatile et suit le cycle de vie de l'onglet. Possède un identifiant client unique.

Le groupe de clients est un ensemble de clients qui partagent des données locales. Les clients de ce groupe de clients partagent l’état même lorsqu’ils sont hors ligne.

Client Group utilise un cache persistant sur disque qui se distingue par le paramètre name du constructeur Replicache. Tous les clients appartenant à un groupe de clients portant le même nom partagent le même cache.

La vue client

Le client dispose d'une carte ordonnée de paires clé-valeur dans le cache persistant, appelée Vue Client. Client View est constitué de données d'application et est synchronisé avec les données du serveur. La raison pour laquelle on l'appelle Vue Client est que différents clients peuvent avoir des données de serveur dans différentes Vues Client. Cela signifie que chaque client voit l'état du serveur différemment.

L'accès à la vue client est très rapide. La latence de lecture est inférieure à 1 ms et la plupart des appareils ont un débit de 500 Mo/s.

Il est recommandé de le lire et de l'utiliser directement à partir de la vue client plutôt que de copier la vue client séparément en utilisant useState à partir d'un endroit comme React et de la télécharger en mémoire. Lorsque le mutateur modifie la vue client, l'abonnement est déclenché afin que l'interface utilisateur soit mise à jour

.

Abonnements

La fonction Subscribe reçoit l'argument ReadTransaction et implémente la lecture depuis Replicache. Chaque fois que cet abonnement devient obsolète en raison d'une modification des données de réplication, la fonction d'abonnement est à nouveau exécutée. Si ce résultat change, la valeur est mise à jour et l'interface utilisateur est également mise à jour.

Si vous configurez l'interface utilisateur via l'abonnement, vous pouvez toujours la maintenir à jour.

import {Replicache} from "replicache";

const rep = new Replicache({
  name: userID,
  ...
});

console.log(rep.clientID);

Mutations

La mutation fait référence à la tâche de modification des données Replicache. Le sujet qui reçoit des mutations et modifie réellement les données est appelé un mutateur.

Au démarrage, plusieurs Mutators sont enregistrés dans Replicache, mais ce ne sont en réalité que des fonctions nommées. createTodo et markTodoComplete ci-dessous sont des mutateurs qui modifient les données Replicache via WriteTransaction.

const todos = useSubscribe(rep, async tx => {
  return await tx.scan({prefix: 'todo/'}).toArray();
});
return (
  <ul>
    {todos.map(todo => (
      <li key={todo.id}>{todo.text}</li>
    ))}
  </ul>
);

Mutator fonctionne comme suit. Lorsque le mutateur opère, les données changent et les abonnements qui y sont liés sont déclenchés, et l'interface utilisateur change également.

const rep = new Replicache({
  ...
  mutators: {
    createTodo,
    markTodoComplete,
  },
});

async function createTodo(tx: WriteTransaction, todo: Todo) {
  await tx.set(`/todo/${todo.id}`, todo);
}

async function markTodoComplete(tx: WriteTransaction,
    {id, complete}: {id: string, complete: boolean}) {
  const key = `/todo/${id}`;
  const todo = await tx.get(key);
  if (!todo) {
    return;
  }
  todo.complete = complete;
  await tx.set(key, todo);
}

En interne, Mutator crée quelque chose appelé mutation. C'est comme un enregistrement d'exécution, mais Replicache crée la mutation suivante.

await rep.mutate.createTodo({id: nanoid(), text: "take out the trash"});

Ces mutations sont marquées comme en attente jusqu'à ce qu'elles soient transmises au serveur et complètement synchronisées.

Détails de synchronisation

Maintenant, voici les détails de Sync, qui peut être considéré comme le cœur de Replicache. La synchronisation se fait sur le serveur.

Le modèle de synchronisation de réplique

(Désormais, l’expression « état » fait référence à l’état des données (espace clé-valeur) constitué de plusieurs paires clé-valeur.)

Le problème de synchronisation que Replicache tente de résoudre se produit lorsque plusieurs clients changent le même état en même temps et que les conditions suivantes existent.

1. L'état du serveur est la source de la vérité. Il est exprimé comme canonique.
2. Les changements dans l’état local du client sont immédiatement reflétés. C'est ce qu'on appelle spéculatif.
3. Le serveur doit appliquer les modifications exactement une fois et les résultats doivent être prévisibles. Les modifications appliquées au serveur doivent pouvoir raisonnablement fusionner avec les modifications locales sur le client.

Le dernier élément parmi ceux-ci est la « fusion raisonnable » des modifications du serveur avec l'état local, ce qui est un sujet intéressant. Pour une « fusion rationnelle », les situations suivantes doivent être considérées.

• Si les modifications locales n'ont pas encore été appliquées au serveur. Dans ce cas, vous devez vous assurer que les modifications locales ne disparaissent pas de l'interface utilisateur de l'application même si un nouvel état est récupéré du serveur. Après avoir reçu le nouvel état du serveur, toutes les modifications locales existantes doivent être réexécutées en plus de l'état du serveur.

• Lorsque les modifications locales apportées sur le client ont déjà été envoyées au serveur et reflétées dans l'état du serveur. Dans ce cas, veillez à ne pas appliquer deux fois les modifications locales. Les modifications locales ne doivent pas être réappliquées

• S'il y a d'autres clients qui ont modifié l'état du serveur pour le même état. Dans ce cas, comme dans le premier cas, les modifications locales doivent être refaites en fonction du statut reçu du serveur. Cependant, étant donné que des conflits peuvent survenir sur la même ressource, la logique de fusion doit être soigneusement planifiée. Écrivez cette logique dans le Mutator.

Suivons le processus de fonctionnement du Mutateur.

Exécution locale

Le mutateur opère localement et la valeur du réplicache change selon la logique du mutateur. Dans le même temps, ce client crée une mutation avec un mutationId qui augmente séquentiellement. Les mutations sont mises en file d'attente comme mutations en attente

.

Pousser

Les mutations en attente sont envoyées au point de terminaison push (replicache-push) implémenté sur le serveur.

la mutation change l'état canonique en exécutant le mutateur implémenté sur le serveur. Lors de l'application de la mutation, le dernier identifiant de mutation de ce client est mis à jour et devient une valeur qui vous permet de savoir à partir de quelle mutation réappliquer lorsque ce client effectuera le prochain pull

.

Une mutation en attente appliquée localement génère un résultat spéculatif, et une mutation appliquée au serveur génère un résultat canonique. Les mutations appliquées au serveur sont confirmées et ne seront plus exécutées localement. Même si la même mutation renvoie un résultat différent, le résultat canonique du serveur est prioritaire, donc le résultat du client change

.

Tirer

Replicache envoie périodiquement une requête au point de terminaison d'extraction (replicache-pull) pour récupérer le dernier état et mettre à jour l'interface utilisateur.

La requête Pull inclut le cookie et le clientGroupId, et renvoie le nouveau cookie, le correctif et le lastMutationIDChanges.

Le cookie est utilisé pour distinguer l'état du serveur détenu par le client. Toute valeur permettant de suivre la différence entre les états du serveur et du client est suffisante. Vous pouvez le considérer comme une « version » globale qui change chaque fois que l’état de la base de données change. Vous pouvez également utiliser une stratégie de cookies pour suivre une gamme de données plus spécifique.

lastMutationIdChanges est une valeur représentant le dernier ID de mutation appliqué par le serveur pour chaque client. Toutes les mutations avec un mutationID inférieur à cette valeur ne doivent plus être considérées comme en attente mais confirmées.

Rebase

Lorsqu'un client reçoit un pull, le patch doit être appliqué à l'état local. Cependant, étant donné que la mutation en attente aurait affecté l’état local actuel, le correctif ne peut pas être appliqué directement à l’état local. Au lieu de cela, annulez la mutation locale en attente, appliquez d’abord le correctif reçu en tant que pull, puis appliquez à nouveau la mutation locale en attente.

Pour permettre ce type d'annulation et de réapplication, Replicache a été conçu de manière similaire à Git. Vous pouvez considérer l'état du serveur comme la branche principale, et l'état modifié par une mutation localement en attente comme la branche de développement, recevoir un pull du serveur vers la branche principale et rebaser le développement vers la branche principale.

Les conflits pouvant survenir lors du rebase seront discutés séparément ci-dessous.

Pousser

Poke, comme expliqué ci-dessus, est un message d'indice que le serveur demande au client d'extraire.

Résolution des conflits

Les conflits de fusion sont inévitables dans les systèmes distribués tels que Replicache. La fusion est nécessaire pendant le processus pull and push. La fusion doit être effectuée de manière à rendre le résultat de la fusion prévisible et à correspondre à l'objectif de l'application.

S'il s'agit d'une application de réservation de salle de conférence, une seule demande doit être approuvée en cas de conflit. Par conséquent, vous devez adopter une méthode de fusion qui n'approuve que les clients ayant effectué des réservations en premier.

En revanche, s'il s'agit d'une application Todo, le but de la liste Todo est que les deux modifications soient approuvées même si des ajouts surviennent en même temps.

Un conflit de fusion se produit dans les deux situations suivantes.

1. Quand les modifications locales seront appliquées au serveur. En effet, le statut lorsqu'il est appliqué localement et le statut lorsqu'il est appliqué sur le serveur peuvent être différents.

2. Lors du rebasage. En effet, le statut peut être différent une fois appliqué.

Replicache reconnaît que la méthode de fusion doit être implémentée différemment selon l'objectif de l'application, elle permet donc aux développeurs de l'implémenter. Les développeurs peuvent implémenter cette logique via Mutator.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!