Deja de sincronizar todos los datos

Un nuevo enfoque para la replicación en el edge

• La sincronización de datos es un problema más difícil de lo que parece. Las soluciones existentes suelen dividirse entre sincronizar el conjunto completo de datos con el cliente o rastrear cambios lógicos.
• Graft fue diseñado para resolver estos problemas y es un motor de almacenamiento de código abierto que combina una replicación física simple con una replicación lógica eficiente.

Sincronización perezosa: sincroniza a la velocidad que quieras

• Graft permite que el cliente elija cuándo sincronizar, por lo que es ideal para entornos edge con conectividad de red intermitente.
• El servidor ofrece un índice de las páginas que cambiaron desde el último snapshot del cliente, y el cliente puede traer de forma selectiva solo los datos que necesita.

Sincronización parcial: sincroniza solo lo necesario

• En entornos edge no es posible descargar el conjunto completo de datos, por lo que Graft admite sincronización parcial para traer selectivamente solo las páginas necesarias.
• Graft puede precargar las páginas necesarias aprovechando algoritmos de predicción generales y conocimiento del dominio.

Edge: sincronización cerca de donde se necesita

• Graft distribuye los datos a través de servidores edge en todo el mundo, manteniendo baja latencia y alta capacidad de respuesta sin importar dónde esté el usuario.
• El cliente está diseñado para ser liviano, por lo que puede integrarse fácilmente en navegadores, apps móviles y entornos serverless.

Consistencia: sincronización segura

• Graft ofrece un modelo de consistencia fuerte para manejar de forma segura los conflictos entre clientes.
• Los clientes pueden obtener una vista consistente de los datos mediante un modelo de aislamiento por snapshots, y las escrituras se serializan estrictamente.

¿Qué se puede construir con Graft?

• Graft proporciona una base sólida para una amplia variedad de aplicaciones nativas del edge.
• Hace posibles las apps offline-first, los datos multiplataforma, las réplicas de lectura sin estado y la replicación de datos arbitrarios.

Extensión de SQLite para Graft (libgraft)

• libgraft es una extensión nativa de SQLite que replica solo la parte de la base de datos que el cliente realmente usa, permitiendo ejecutar SQLite incluso en entornos con recursos limitados.
• Ofrece funciones como replicación asíncrona, replicación parcial perezosa, aislamiento por snapshots y recuperación a un punto en el tiempo.

Cómo participar

• Graft se desarrolla en GitHub y recibe con gusto contribuciones de la comunidad.
• Puedes unirte a Discord o enviar comentarios por correo electrónico.
• También puedes registrarte en la lista de espera del servicio administrado de Graft.

Hoja de ruta

• Graft sigue en desarrollo y tiene planes para soporte de WebAssembly, integración con SQLSync y soporte para varias bibliotecas cliente.
• También se añadirán funciones como menor latencia de escritura, recolección de basura, autenticación y autorización, volume forking y manejo de conflictos.

Comparación con otras soluciones de replicación de SQLite

• Graft tiene ventajas distintivas frente a mvSQLite, Litestream, cr-sqlite, Cloudflare Durable Objects, Cloudflare D1, Turso & libSQL, rqlite & dqlite y Verneuil.
• Sus principales diferenciales son la replicación parcial, el soporte para estructuras de datos arbitrarias y la replicación eficiente en el edge.

[GN⁺]

Opinión de Hacker News

• No se entiende el modelo de consistencia

  • El cliente de Graft hace commit localmente e intenta un commit remoto de forma asíncrona
  • Si dos clientes hacen commit al mismo tiempo basándose en el mismo snapshot, uno tiene éxito y el otro falla
  • La API solo ofrece una operación de commit única
  • Si el commit local tiene éxito pero falla la propagación asíncrona, surge el problema de tener que hacer rollback
  • El concepto de "commit" está mezclado entre varios significados

• El autor de Graft agradece los comentarios

  • Está asistiendo al Antithesis BugBash en Washington DC
  • Quiere conocer gente que esté en Washington

• Entiende que el modelo de consistencia es similar a git

  • Se puede modificar una copia local y, al hacer "push", pueden surgir conflictos
  • No hay una forma clara de detectar limpiamente los conflictos
  • Pueden surgir conflictos por conflictos de lectura

• Cuando el cliente obtiene Graft, puede saber exactamente qué cambió

  • Lo compara con el manifiesto de Cloud-Backed SQLite
  • No se necesita cómputo en el servidor

• No menciona detalles de implementación

  • Se necesita una capa de sincronización para que los desarrolladores de apps no tengan que preocuparse por la sincronización
  • Puede permitir sincronización personal sin suscripción

• Considera que usar VFS es un "hack" interesante

  • Está desarrollando su propio motor de sincronización para un IDE offline-first
  • Resolver conflictos usando una estructura de árbol es un desafío

• Un proyecto que usa el algoritmo Leap resulta muy interesante

  • Es fácil enfocarse en la integración con SQLite, pero aquí se aborda como un problema de almacenamiento distribuido más general y de nivel más bajo
  • Una solución general sin experiencia concreta puede ser riesgosa

• Puede haber problemas cuando el cliente móvil está en una conexión lenta

  • Propone un enfoque híbrido que detecte sincronización lenta y envíe consultas directamente al servidor

• Resulta interesante el enfoque de usar páginas como unidad básica de sincronización

  • Pueden ocurrir conflictos con muchos usuarios concurrentes
  • OT o CRDT podrían ser mejores

• Es un problema muy desafiante

  • Le gustaría probarlo en una app de React Native