Yjs y Automerge

Saber que un CRDT converge es una cosa; construir uno que edite un documento de cien mil palabras a sesenta cuadros por segundo, sincronice por una red intermitente enviando kilobytes y se integre con el editor que ya usas es otra muy distinta. Entre la teoría del semirretículo y el editor colaborativo real hay años de ingeniería, y esa ingeniería está encarnada hoy en dos librerías que se reparten casi todo el terreno: Yjs y Automerge. No son competidoras en el sentido trivial de hacer lo mismo peor o mejor; son dos filosofías sobre qué debe optimizar un CRDT en producción. Yjs pregunta cómo hacer que fundir sea tan rápido y tan compacto que puedas colaborar en tiempo real sobre cualquier estructura, y sacrifica sin remordimiento lo que haga falta —la historia, por ejemplo— en el altar del rendimiento. Automerge pregunta cómo hacer que tus datos tengan la forma limpia de un JSON y arrastren su historia completa como un repositorio de Git, y acepta pagar por ello en peso y velocidad. Esta lección te da el modelo mental de cada una, su código esencial y, sobre todo, el criterio para elegir: porque la pregunta correcta no es cuál es mejor, sino qué estás dispuesto a sacrificar.

Yjs: rendimiento y tipos compartidos

Yjs, obra de Kevin Jahns, es el CRDT más usado en producción para colaboración en tiempo real, y su seña de identidad es la velocidad. En su núcleo late YATA —Yet Another Transformation Approach—, un CRDT de secuencia optimizado hasta el extremo para que insertar, borrar y fundir sean baratísimos incluso en documentos enormes. Por encima de ese núcleo, Yjs expone un puñado de tipos compartidos que se comportan como estructuras normales pero son CRDTs por dentro: Y.Map para objetos, Y.Array para listas y Y.Text para texto rico. Todos cuelgan de un Y.Doc, la raíz del documento. Los editas con una API mutable y familiar, y Yjs se encarga de que cada cambio genere una actualización binaria diminuta —un delta— que representa solo lo que cambió, no el documento entero.

import * as Y from 'yjs'
import { WebsocketProvider } from 'y-websocket'

const doc = new Y.Doc()
const provider = new WebsocketProvider('wss://demo', 'sala-1', doc)

const texto = doc.getText('contenido')
texto.insert(0, 'Hola')          // edicion local mutable; se propaga sola

doc.on('update', (delta: Uint8Array) => {
  // delta binario y compacto: viaja solo el cambio, nunca el documento entero
})

Dos piezas hacen a Yjs desplegable en el mundo real. La primera son los providers: Yjs no sabe nada de red, y delega el transporte en módulos intercambiables —y-websocket para un servidor central, y-webrtc para conexiones entre pares, y-indexeddb para persistir en el navegador—. Puedes apilar varios a la vez y cambiarlos sin tocar la lógica de datos. La segunda es la sincronización por vectores de estado: antes de enviar nada, dos réplicas intercambian un resumen compacto de qué operaciones ya conocen, y así cada una manda al otro únicamente lo que le falta, sin retransmitir lo que ya tiene. Es la diferencia entre sincronizar un documento grande en unos bytes o en megabytes.

Hay un tipo de estado que nunca debería vivir en el Y.Doc: el efímero. La posición del cursor, la selección, el color y el nombre de cada colaborador cambian decenas de veces por segundo y no tiene sentido persistirlos ni fundirlos como parte del documento. Yjs lo resuelve con un canal aparte, el protocolo awareness, que propaga presencia sin ensuciar el CRDT.

import { WebsocketProvider } from 'y-websocket'

provider.awareness.setLocalState({ usuario: 'Ada', cursor: 42 })
provider.awareness.on('change', () => {
  const presentes = provider.awareness.getStates() // quien esta y donde mira
})

Automerge: un documento con historia

Automerge, ligado al trabajo de Martin Kleppmann, hace la apuesta contraria: prioriza que tus datos tengan la forma de un documento JSON limpio y que conserven su historia completa. Un documento Automerge es un objeto anidado —mapas, listas, texto, números— que editas a través de una API inmutable: no mutas el documento, sino que llamas a change con una función que describe la modificación, y recibes un documento nuevo. Por dentro, cada llamada a change produce un cambio identificado por un hash, y esos cambios se enlazan en un grafo acíclico dirigido exactamente como los commits de Git, con lo que puedes inspeccionar la historia, atribuir cada edición a su autor y viajar a cualquier estado pasado.

import { next as Automerge } from '@automerge/automerge'

let doc = Automerge.init<{ items: string[] }>()
doc = Automerge.change(doc, (d) => { d.items = [] })     // API inmutable
doc = Automerge.change(doc, (d) => { d.items.push('leche') })

const historia = Automerge.getHistory(doc)   // cada cambio queda registrado
const binario = Automerge.save(doc)          // codificacion columnar compacta

El núcleo de Automerge se reescribió en Rust y se ejecuta en el navegador vía WebAssembly, lo que cerró buena parte de la brecha de rendimiento con Yjs sin renunciar a su modelo. La fusión de dos réplicas divergentes es explícita y limpia, y devuelve un documento nuevo que ambas partes comparten, con el grafo de cambios reconstruido a partir de los hashes que cada una aportó.

// dos replicas editaron por separado; merge las reconcilia sin arbitro
let miDoc = Automerge.change(base, (d) => { d.items.push('pan') })
let suDoc = Automerge.change(base, (d) => { d.items.push('huevos') })
miDoc = Automerge.merge(miDoc, suDoc)   // ahora contiene pan y huevos, converge

La historia no es un adorno: es la propiedad que define a la librería. Donde Yjs, por defecto, descarta el pasado para ir ligero, Automerge lo guarda todo, y esa decisión habilita casos —auditoría, atribución, deshacer profundo, ramas y fusiones al estilo de Git— que en Yjs habría que construir aparte. Cada réplica se identifica con un actor único, cada cambio conoce a sus predecesores, y el conjunto forma un grafo que puedes recorrer, comparar y bifurcar. El precio es un documento más pesado y una biblioteca más grande, la contrapartida honesta de guardar cada paso del camino.

Dos filosofías del mismo problema

Ambas librerías resuelven el mismo problema —fundir ediciones concurrentes sin árbitro— y ambas comparten rasgos: transporte agnóstico, protocolos de sincronización binarios y eficientes, y bindings o integraciones para editores. La diferencia está en qué optimizan, y esa diferencia debe guiar tu elección.

El flujo de sincronización, en cambio, es conceptualmente idéntico en las dos, y merece la pena visualizarlo porque es el corazón de la colaboración en tiempo real: cada réplica anuncia qué conoce, recibe solo lo que le falta y funde localmente sin pedir permiso.

sequenceDiagram
participant A as Replica A
participant B as Replica B
A->>B: vector de estado, esto ya conozco
B->>A: vector de estado, esto conozco yo
B->>A: delta binario con lo que a A le falta
A->>B: delta binario con lo que a B le falta
Note over A,B: cada una funde local, convergen sin arbitro

La elección práctica, entonces, se reduce a una pregunta sobre tus prioridades. Si construyes un editor de texto colaborativo de alto rendimiento y quieres enchufarte al ecosistema de editores más rico, Yjs es la elección de defecto. Si construyes una aplicación cuyos datos son documentos estructurados que quieres versionar, auditar y ramificar —una app de notas con historial, una herramienta con deshacer profundo, un sistema donde importa quién cambió qué y cuándo—, Automerge encaja mejor. Ninguna es universalmente superior; cada una hizo un sacrificio distinto, y elegir bien es reconocer cuál de esos sacrificios puedes permitirte.