𝗖𝗥𝗗𝗧𝘀 𝗲𝗻 𝗞𝗼𝘁𝗹𝗶𝗻 𝗠𝘂𝗹𝘁𝗶𝗽𝗹𝗮𝘁𝗳𝗼𝗿𝗺 : Éliminez votre serveur de synchronisation

La plupart des équipes construisent un serveur central pour gérer les conflits de données. Le serveur reçoit les écritures, choisit un gagnant et espère que tout se passera bien. Cela crée un point de défaillance unique et un code complexe à maintenir.

Les types de données répliqués sans conflit (CRDTs - Conflict-Free Replicated Data Types) changent la donne. Chaque appareil atteint le même état sans avoir besoin d'un chef central. C'est une garantie mathématique.

Vous pouvez remplacer votre backend de synchronisation par un simple stockage de blobs. Votre serveur devient un relais qui conserve des blobs de données. Il n'a pas besoin de comprendre vos données.

Utilisez ces primitives pour vos applications mobiles :

• LWW-Register : Utilisez pour les profils utilisateurs et les paramètres. • G-Counter : Utilisez pour les analyses ou les compteurs de vues. • PN-Counter : Utilisez pour les inventaires ou les totaux de paniers. • OR-Set : Utilisez pour les tags et les favoris.

Pour la plupart des applications mobiles, les LWW-Registers et les OR-Sets couvrent presque tout.

Conseil d'implémentation : Lorsque vous construisez un LWW-Register, incluez toujours un nodeId. Si deux mises à jour ont exactement le même horodatage, le nodeId sert de départage. Sans cela, vos appareils ne se synchroniseront pas sur le même état.

Basé sur l'état (State-based) vs Basé sur les opérations (Operation-based) :

Choisissez le mode basé sur l'état (CvRDT) pour le mobile. Cela fonctionne sur des réseaux peu fiables car le processus de fusion est idempotent. Si une synchronisation échoue à mi-chemin, il suffit de réessayer.

Évitez le mode basé sur les opérations (CmRDT) au début. Il nécessite une livraison "exactly-once" (exactement une fois). Construire une telle infrastructure sur les réseaux mobiles est difficile et ajoute la complexité que vous souhaitez justement éviter.

L'Architecture :

  1. Construisez votre logique CRDT dans le module commonMain de votre projet Kotlin Multiplatform.
  2. Utilisez SQLDelight pour stocker les données localement.
  3. Synchronisez les blobs de données vers un service comme S3 ou Cloud Storage.
  4. Votre backend reste simple et économique.

Arrêtez de construire des moteurs de synchronisation complexes. Utilisez les CRDT pour déplacer la logique vers le client. Cela vous permet de vous concentrer sur la création de fonctionnalités plutôt que sur la gestion des rotations de serveurs.

Source : https://dev.to/software_mvp-factory/crdts-in-kotlin-multiplatform-kill-your-sync-server-28n8