Motores de sincronización

En el nivel treinta y seis construiste a mano una cola de mutaciones offline: encolar la intención, aplicarla optimistamente, drenarla al reconectar, reconciliar. Funcionaba, pero era artesanía frágil, y al final de aquella lección insinuamos que en producción rara vez se escribe todo eso desde cero. Los motores de sincronización son la respuesta industrial a ese problema: infraestructura que generaliza tu cola artesanal hasta convertirla en una base de datos local que se mantiene sola al día con el servidor, en ambos sentidos, sin que tu aplicación vuelva a escribir un fetch. La idea es tan simple de enunciar como difícil de implementar: tu app consulta una base de datos que vive en el dispositivo —un SQLite embebido, un store reactivo— y el motor se encarga, en segundo plano, de replicar hacia arriba tus escrituras y hacia abajo los cambios del servidor. La red desaparece de tu código; en su lugar queda una consulta local que siempre está fresca. Cuatro motores se disputan hoy esta categoría naciente —Electric SQL, Zero, Jazz y PowerSync—, y aunque sus arquitecturas difieren, todos giran alrededor del mismo eje y tropiezan con el mismo muro: la base de datos entera nunca cabe en el cliente, así que todos necesitan una forma de decir qué parte sincronizar. Esta lección los recorre y te deja el mapa de esa categoría.

La idea común: una base de datos local que se sincroniza sola

El patrón que comparten los cuatro motores es una inversión del acceso a datos que ya reconoces de la primera lección del nivel. En la arquitectura tradicional tu app pide datos al servidor con fetch, recibe una respuesta, la cachea y la muestra; cada pantalla es una petición y cada petición un punto de espera y de fallo. En la arquitectura de un motor de sincronización tu app no pide nada por la red: consulta una base de datos local que ya tiene los datos, y el motor los pone y los mantiene ahí. La consulta es instantánea porque es local, funciona sin red porque los datos ya están, y se actualiza sola porque el motor propaga los cambios del servidor en cuanto llegan.

flowchart LR
APP[tu aplicacion] -->|consulta local instantanea| LDB[base de datos local]
LDB <-->|replicacion bidireccional| ENG[motor de sincronizacion]
ENG <-->|cambios en streaming| SDB[base de datos del servidor]
style LDB fill:#a6e3a1,color:#11111b
style ENG fill:#cba6f7,color:#11111b

La consecuencia para quien programa es enorme: desaparecen la capa de API, la gestión manual del caché, la invalidación, los estados de carga y de error de cada petición. Tu código se parece más al de una app de escritorio de los noventa que consulta su base de datos local, con la diferencia de que esa base de datos está mágicamente sincronizada con un servidor y con los demás usuarios. El motor absorbe toda la complejidad que en el nivel treinta y seis escribiste a mano: la cola durable de escrituras, el drenado al reconectar, los reintentos, la reconciliación de identificadores. Lo que era tu problema pasa a ser su problema.

Conviene distinguir dos direcciones que todo motor gestiona por separado. El camino de lectura —del servidor al cliente— replica hacia abajo los datos que a este usuario le tocan y los mantiene frescos ante cada cambio en el servidor. El camino de escritura —del cliente al servidor— toma las mutaciones locales, las encola y las sube, donde el servidor las valida y, si las acepta, se convierten en cambios que el camino de lectura propaga de vuelta a todas las réplicas. Algunos motores son fuertes sobre todo en el camino de lectura y dejan la escritura como una API tradicional; otros cierran el círculo entero. Saber cuál de los dos caminos te importa más es la primera pregunta al elegir.

Cuatro motores, cuatro apuestas

La categoría es joven y sus miembros divergen en qué optimizan y en qué base de datos del servidor asumen. Conviene conocer las cuatro apuestas dominantes.

Estas apuestas no son intercambiables. Electric SQL y PowerSync parten de que ya tienes una base de datos relacional y una fuente de verdad en el servidor, y se limitan a proyectar subconjuntos de ella al cliente; son la elección natural cuando modernizas un backend existente. Zero reimagina la relación entre consulta y datos, tratando cada consulta viva como una suscripción reactiva que el servidor alimenta, y brilla cuando quieres una experiencia reactiva de extremo a extremo sin pensar en caché. Jazz es el más ambicioso y el más opinado: al construirse sobre CRDTs y traer permisos y cifrado de fábrica, acerca la promesa completa del manifiesto local-first, a cambio de adoptar su modelo de datos en lugar del tuyo.

// Electric: una shape declara el subconjunto de una tabla que se sincroniza
const stream = new ShapeStream({
  url: 'https://api.ejemplo/v1/shape',
  params: { table: 'tareas', where: "proyecto_id = '42'" },
})
// el cliente lee de un store local que Electric mantiene al dia

// Zero: la consulta ES la unidad de sincronizacion; su resultado sigue vivo
const tareas = z.query.tarea
  .where('proyectoId', '=', '42')
  .where('completada', '=', false)
  .orderBy('creada', 'desc')
// el resultado se refresca solo cuando el servidor cambia

El contraste con Jazz es instructivo, porque no proyecta filas de una base de datos ajena sino que los datos nacen ya como CRDTs con permisos incorporados. En lugar de una tabla en el servidor y una shape que la filtra, tienes un grafo de valores colaborativos cuya visibilidad la decide un grupo, y el sync y el cifrado son consecuencia del modelo, no una capa añadida.

// Jazz: los datos son CoValues, CRDTs con permisos por grupo integrados
const lista = ListaDeTareas.create({ titulo: 'Compra' }, { owner: grupo })
lista.push(Tarea.create({ texto: 'Pan', hecha: false }, { owner: grupo }))
// el grupo decide quien lee y escribe; el sync y el cifrado van de fabrica

Replicación parcial: el muro que todos rodean

Hay un motivo por el que los cuatro motores necesitan una shape, una consulta o una regla, y no basta con decir sincroniza todo: la base de datos del servidor no cabe en el cliente. Un Postgres de producción tiene gigabytes o terabytes; un teléfono no puede ni debe replicarlos. Por eso la replicación parcial es el problema central de la categoría, y la forma de declarar qué subconjunto viaja es la decisión de diseño que distingue a cada motor. Electric la llama shape —un filtro sobre una tabla—; Zero la deriva de tus consultas; PowerSync la codifica en reglas de sincronización que mapean usuarios a filas; Jazz la resuelve por el grafo de CoValues a los que un usuario tiene acceso. Distintos nombres para la misma pregunta: qué porción del universo de datos merece vivir en este dispositivo, para este usuario, ahora.

Esa pregunta arrastra dos más que ningún motor puede esquivar. La primera es la autorización: si el cliente recibe un subconjunto de la base de datos, el motor debe garantizar que ese subconjunto es exactamente el que el usuario tiene permiso de ver, porque una shape mal filtrada es una fuga de datos. La segunda es la reactividad del propio subconjunto: cuando cambian los criterios —el usuario abre otro proyecto, gana un permiso, filtra distinto— la porción replicada debe crecer o encogerse sola, sin descargar de nuevo lo que ya tenía. Resolver bien la replicación parcial, con su autorización y su reactividad, es lo que separa un motor de juguete de uno de producción, y es donde estas herramientas concentran su ingeniería más difícil.