Pare de sincronizar todos os dados

Uma nova abordagem para replicação na edge

• A sincronização de dados é um problema mais difícil do que parece. As soluções existentes geralmente se dividem entre sincronizar o conjunto completo de dados com o cliente ou rastrear alterações lógicas.
• O Graft foi projetado para resolver esse problema e é um mecanismo de armazenamento open source que combina replicação física simples com replicação lógica eficiente.

Sincronização preguiçosa: sincronize no ritmo que você quiser

• O Graft permite que o cliente escolha quando sincronizar, o que o torna adequado para ambientes de edge com conexão de rede intermitente.
• O servidor fornece o índice das páginas alteradas desde o último snapshot do cliente, e o cliente pode buscar seletivamente apenas os dados de que precisa.

Sincronização parcial: sincronize apenas o necessário

• Em ambientes de edge, não é possível baixar o conjunto completo de dados, por isso o Graft oferece suporte à sincronização parcial, buscando seletivamente apenas as páginas necessárias.
• O Graft pode buscar antecipadamente as páginas necessárias usando algoritmos de predição genéricos e conhecimento de domínio.

Edge: sincronização perto de onde é necessário

• O Graft fornece dados por meio de servidores de edge no mundo todo, mantendo baixa latência e alta responsividade independentemente de onde o usuário esteja.
• O cliente foi projetado para ser leve e pode ser integrado facilmente a navegadores, apps móveis e ambientes serverless.

Consistência: sincronização segura

• O Graft oferece um modelo de consistência forte para lidar com segurança com conflitos entre clientes.
• Os clientes podem obter uma visão consistente dos dados por meio do modelo de isolamento por snapshot, e as escritas são estritamente serializadas.

O que dá para criar com o Graft?

• O Graft fornece uma base poderosa para vários aplicativos edge-native.
• São possíveis apps offline-first, dados multiplataforma, réplicas de leitura sem estado e replicação de dados arbitrários.

Extensão SQLite do Graft (libgraft)

• O libgraft é uma extensão nativa do SQLite que replica apenas a parte do banco de dados realmente usada pelo cliente, permitindo executar SQLite mesmo em ambientes com recursos limitados.
• Ele oferece recursos como replicação assíncrona, replicação parcial preguiçosa, isolamento por snapshot e recuperação para um ponto no tempo.

Como participar

• O Graft está sendo desenvolvido no GitHub e recebe contribuições da comunidade.
• É possível participar no Discord ou enviar feedback por e-mail.
• Você pode entrar na lista de espera do serviço gerenciado do Graft.

Roadmap

• O Graft ainda está em desenvolvimento e há planos para suporte a WebAssembly, integração com SQLSync e suporte a várias bibliotecas cliente.
• Também estão previstas funcionalidades como redução da latência de escrita, coleta de lixo, autenticação e autorização, volume forking e tratamento de conflitos.

Comparação com outras soluções de replicação para SQLite

• O Graft tem vantagens únicas em comparação com mvSQLite, Litestream, cr-sqlite, Cloudflare Durable Objects, Cloudflare D1, Turso & libSQL, rqlite & dqlite, Verneuil e outros.
• Sincronização parcial, suporte a estruturas de dados arbitrárias e replicação eficiente na edge são seus principais diferenciais.

[GN⁺]

Comentários do Hacker News

• O modelo de consistência não está claro

  • O cliente Graft faz commit localmente e tenta fazer o commit remoto de forma assíncrona
  • Se dois clientes fizerem commit ao mesmo tempo com base no mesmo snapshot, um terá sucesso e o outro falhará
  • A API oferece apenas uma única operação de commit
  • Se a propagação assíncrona falhar depois que o commit local tiver sido bem-sucedido, surge o problema de precisar fazer rollback
  • Há uma mistura de vários significados para o conceito de "commit"

• O autor do Graft agradece

  • Está participando do Antithesis BugBash em Washington, DC
  • Gostaria de encontrar pessoas que estejam em Washington

• Entende que o modelo de consistência é semelhante ao do git

  • É possível alterar a cópia local e ter conflitos ao fazer "push"
  • Não há uma forma limpa de detectar conflitos
  • Conflitos podem ocorrer por causa de conflitos de leitura

• Quando o cliente busca o Graft, ele consegue saber exatamente o que mudou

  • Compara com o manifesto do Cloud-Backed SQLite
  • Não é necessário cálculo no servidor

• Não entra em detalhes de implementação

  • É necessária uma camada de sincronização para que desenvolvedores de apps não precisem se preocupar com sincronização
  • Pode oferecer sincronização pessoal sem assinatura

• Acha divertido usar VFS como um "hack"

  • Está desenvolvendo seu próprio mecanismo de sincronização para uma IDE offline-first
  • Resolver conflitos usando uma estrutura em árvore é um desafio

• O projeto que usa o algoritmo Leap é muito interessante

  • É fácil focar na integração com SQLite, mas a abordagem é tratar isso como um problema de armazenamento distribuído mais geral e de baixo nível
  • Uma solução genérica sem experiência concreta pode ser arriscada

• Podem surgir problemas quando clientes móveis estiverem em conexões lentas

  • Sugere uma abordagem híbrida que detecta sincronização lenta e envia consultas diretamente ao servidor

• A abordagem de usar páginas como unidade básica de sincronização é interessante

  • Podem ocorrer conflitos com muitos usuários simultâneos
  • OT ou CRDT pode ser melhor

• É um problema muito desafiador

  • Gostaria de testar isso em um app React Native