Construire un éditeur de texte collaboratif en temps réel avec Javascript et Webrtc

const dataChannel = peerConnection.createDataChannel('collabEditor', {
 ordered: true
});

`. Cependant, contenteditable est notoirement difficile à synchroniser car il produit un HTML imprévisible sur les navigateurs. Un meilleur choix est une bibliothèque comme Quill.js, qui fournit un modèle de document structuré appelé Parchemin. Vous pouvez également utiliser ProseMirror, qui offre un contrôle encore plus fin sur l'état du document et prend en charge l'édition collaborative nativement via son plugin de collaboration.

Pour ce projet, nous utiliserons Quill car il enlève la complexité de contenteditable tout en nous donnant accès au format delta brut, facile à sérialiser et à transmettre.

Capturer les modifications et envoyer les modifications

Quill émet un événement `text-change` chaque fois que le document change. Vous pouvez écouter cet événement et envoyer le delta à tous les pairs connectés:

quill.on('text-change', function(delta, oldDelta, source) {
 if (source === 'user') {
 dataChannel.send(JSON.stringify(delta));
 }
});

La vérification `source` garantit que vous n'avez diffusé que les modifications apportées par l'utilisateur local, et non les modifications appliquées à distance. Cela empêche les boucles infinies où une modification entrante déclenche une autre modification sortante.

Gestion de la synchronisation et des conflits

Transformation opérationnelle

Lorsque deux utilisateurs éditent le même document simultanément, les conflits sont inévitables. Par exemple, l'utilisateur A insère un caractère à la position 5 tandis que l'utilisateur B supprime la position 3. Sans une stratégie de résolution, le document final diverge. La transformation opérationnelle (OT) est un algorithme éprouvé qui maintient la cohérence des documents en transformant les opérations les unes contre les autres. OT fonctionne en conservant un numéro de version pour chaque opération et en ajustant les opérations entrantes en fonction de l'état actuel.

La mise en œuvre de l'OT à partir de zéro est complexe. Au lieu de cela, considérez l'utilisation d'une bibliothèque comme ot.js ou la logique de transformation intégrée dans ProseMirror. Ces bibliothèques gèrent le levage mathématique lourd pour que vous puissiez vous concentrer sur l'intégration.

Les DTCE en tant que solution de rechange

Contrairement à OT, les CRDT ne nécessitent pas de serveur centralisé ou de commande d'opération; chaque pair maintient une copie locale et réconcilie automatiquement les différences. Des bibliothèques comme Automerge[ ou Yjs[ mettent en œuvre les CRDT et offrent une intégration transparente avec les éditeurs populaires. Yjs, par exemple, a une liaison Quill qui rend presque trivial d'ajouter une collaboration.

Le choix entre OT et CRDT dépend de votre cas d'utilisation. OT a généralement des frais généraux de mémoire plus faibles et fonctionne bien pour les documents texte seulement. Les CRDT sont mieux adaptés pour les structures de données complexes et les scénarios d'édition hors ligne.

Bâtir et écraser

Même avec une résolution de conflit parfaite, envoyer chaque frappe sur le réseau crée du trafic inutile et peut surcharger les pairs. Implémenter un mécanisme de batch qui recueille les modifications pour un court intervalle (50-100 ms) et les envoie en une seule opération. Cela réduit les frais généraux sans sacrifier la sensation en temps réel. Vous pouvez utiliser une simple débonzation sur l'événement `text-change`:

let batch = [];
quill.on('text-change', function(delta) {
 batch.push(delta);
 clearTimeout(batchTimer);
 batchTimer = setTimeout(() => {
 dataChannel.send(JSON.stringify(batch));
 batch = [];
 }, 50);
});

Architecte pour l'échelle et la fiabilité

Gestion des relations entre pairs

Si plus de deux utilisateurs rejoignent le même document, vous faites face à un scénario réseau maillé où chaque pair doit ouvrir une connexion à tous les autres pairs. Cela s'évalue mal parce que le nombre de connexions augmente quadratiquement avec le nombre de participants. Pour les sessions avec plus de 5-6 utilisateurs, envisager d'utiliser une unité de transfert sélective (UGS) ou une unité de contrôle multipoint (UCM) pour relayer les données par le serveur.

Persistance de l'État

WebRTC est éphémère par conception. Si un utilisateur rafraîchit la page, il perd tout état de connexion et le document revient à son état initial. Pour éviter la perte de données, vous avez besoin d'un calque de persistance côté serveur. Stockez l'état du document dans une base de données comme PostgreSQL ou Redis après chaque lot d'éditions. Lorsqu'un nouvel utilisateur se joint, il récupère l'état actuel du serveur avant de se connecter via WebRTC. Cette approche hybride vous donne le meilleur des deux mondes : l'édition pair-à-pair à faible latence et le stockage durable.

Considérations relatives à la sécurité et à la protection des renseignements personnels

Cryptage des canaux de données

Les canaux de données WebRTC sont automatiquement cryptés avec DTLS (Datagram Transport Layer Security). Cela signifie que le contenu de vos modifications est sûr de l'écoute même lorsqu'il voyage à travers des hops de réseau inconnus. Cependant, le canal de signalisation n'est pas crypté par défaut, vous devez donc le servir sur HTTPS et WSS (WebSockets Secure). Ne jamais transmettre des offres ou des réponses en texte simple sur HTTP non crypté.

Authentification et contrôle d'accès

Implémenter un système d'authentification à base de jetons où les utilisateurs obtiennent un jeton signé de votre serveur avant de pouvoir lancer une connexion WebRTC. Le jeton doit contenir le rôle de l'utilisateur & #8217;s (éditeur, visionneur, administrateur) et l'ID du document auquel ils sont autorisés à accéder. Valider ce jeton à la fois sur le serveur de signalisation et dans la logique de l'éditeur pour empêcher des modifications non autorisées.

Prévention des attaques par injection

Si vous utilisez contenteditable, les utilisateurs malveillants pourraient injecter des HTML arbitraires, y compris des scripts. Même avec un éditeur désinfecté comme Quill, vous devriez valider tous les deltas entrants à la fin de la réception. Quill’s delta format est strict, mais vous pouvez ajouter une étape de désinfection supplémentaire qui supprime les attributs inattendus. Ne jamais faire confiance à l'utilisateur, même d'un pair que vous avez authentifié.

Essais et débogage

Simulation de plusieurs utilisateurs

Tester un éditeur collaboratif nécessite au moins deux instances de navigateur. Utilisez des fenêtres incognito ou différents profils de navigateur pour simuler des utilisateurs séparés. Des outils comme BrowserStack[ vous permettent de tester simultanément différents navigateurs et appareils. Faites une attention particulière aux cas de bord tels que les frappes rapides successives, les grandes pâtes simultanées et les interruptions réseau.

Surveillance de la chaîne de données Santé

Les canaux de données WebRTC peuvent tomber en raison de changements de réseau ou de temps d'arrêt NAT. Implémentez un mécanisme de battement du cœur qui envoie un petit message `ping` toutes les 5 secondes. Si aucune réponse n'est reçue en 10 secondes, supposons que la connexion est morte et essayez de la rétablir.

Optimisations de performance

Compression

Les modifications de texte sont petites, mais lorsque de nombreux utilisateurs sont en train de modifier, le volume de messages peut s'additionner. Activez la compression sur le canal de données si votre bibliothèque le supporte. Vous pouvez également compresser la charge utile JSON sur le calque d'application en utilisant une bibliothèque comme `pako` (zlib dans JavaScript).

Synchronisation sélective

Chaque modification n'a pas besoin d'être envoyée à chaque pair. Par exemple, lorsqu'un utilisateur tape rapidement, seulement l'état final après que le clavier compte, pas tous les caractères intermédiaires. Utilisez un mécanisme de détection par défaut : si l'utilisateur tape activement, tamponnez les changements et n'envoyez que le delta consolidé lorsqu'il s'arrête.

Lassitude de rendre

Si le document devient grand (des centaines de pages), le rendu de l'ensemble du contenu de chaque édition entrante peut provoquer le jank de l'interface utilisateur. Implémenter défilement virtuel ou pagination de sorte que seule la partie visible du document soit re-rendue. Ceci est particulièrement important pour les appareils mobiles avec une puissance de traitement limitée.

Déploiement et préparation à la production

Choisir un serveur de signalisation

Pour la production, vous avez besoin d'un serveur de signalisation robuste qui peut gérer des milliers de connexions simultanées. Node.js avec socket.io est un choix populaire en raison de son scalabilité et de mécanismes de repli intégrés. Si vous préférez une solution gérée, considérez des services comme Stream ou Twilio, qui offrent l'infrastructure WebRTC hors de la boîte.

Tester avec de vrais réseaux

Des tests locaux cachent la latence du réseau et la perte de paquets. Déployez votre éditeur dans un environnement de mise en scène et testez avec des pairs sur différents continents. Utilisez des outils comme Wireshark pour analyser le trafic WebRTC et identifier les goulets d'étranglement.

Surveillance et exploitation forestière

Ajoutez une session structurée pour tous les événements WebRTC : changements d'état de connexion, ouverture/fermer le canal de données et opérations de modification. Utilisez un service de logarithme centralisé comme Datadog[ ou Loggly[ pour agréger les journaux de tous les pairs. Cela vous aide à déboguer les problèmes en temps réel et à identifier les modèles qui conduisent à des baisses de connexion.

Conclusion

En tirant parti de la puissance des connexions pair-à-pair, vous pouvez créer une expérience d'édition qui se sent instantanée et s'échelle sans infrastructure de serveur coûteuse. Les composants clés sont un mécanisme de signalisation fiable, une surface d'éditeur structurée comme Quill ou ProseMirror, et une stratégie de résolution de conflits robuste utilisant OT ou CRDTs.

Pour les petites équipes, le WebRTC pur avec un serveur de signalisation léger est idéal. Pour les déploiements plus importants, l'ajout d'une couche de serveur pour la persistance et l'acheminement sélectif vous donne le contrôle dont vous avez besoin. Quel que soit le chemin que vous choisissez, les principes décrits ici serviront de base solide pour construire des outils collaboratifs prêts à la production.