Entendendo Modelos de Dados Offline-First: Esquemas e Estruturas

Entendendo Modelos de Dados Offline-First: Esquemas e Estruturas

O que é um Modelo de Dados Offline-First?

Imagine que você está construindo um aplicativo de lista de tarefas. Normalmente, você salvaria tudo no servidor na nuvem. Mas e se o usuário perder a conexão com a internet? Com um modelo offline-first, você primeiro salva os dados localmente no dispositivo, e depois sincroniza com o servidor quando a conexão retorna.

É como ter um caderno pessoal (seu banco de dados local) onde você escreve suas tarefas imediatamente, e depois envia uma cópia para um arquivo compartilhado (servidor) quando consegue se conectar.

Os Três Pilares de um Bom Esquema Offline-First

1. Identificadores Únicos (IDs)

Quando você trabalha offline, o servidor não pode gerar IDs para você. Você precisa criar IDs localmente que funcionem mesmo sem conexão. A solução mais comum é usar UUIDs (identificadores universalmente únicos).

// Exemplo simples de estrutura com UUID
struct Tarefa {
    std::string id;           // UUID gerado localmente
    std::string titulo;
    bool concluida;
    long timestamp;           // Quando foi criada
};

Por que UUIDs? Porque dois dispositivos diferentes podem criar tarefas ao mesmo tempo, e ambas precisam de IDs únicos que não entrem em conflito.

2. Rastreamento de Mudanças

Você precisa saber o que mudou para sincronizar corretamente. Adicione campos que rastreiem o estado:

struct Tarefa {
    std::string id;
    std::string titulo;
    bool concluida;
    long criadoEm;            // Timestamp de criação
    long modificadoEm;        // Timestamp da última mudança
    bool sincronizado;        // Já foi enviado ao servidor?
    std::string status;       // "pendente", "sincronizado", "conflito"
};

Esses campos são como etiquetas que dizem: "Esta tarefa foi modificada às 14:30 e ainda não foi enviada ao servidor".

3. Suporte a Conflitos

Aqui está um cenário real: você edita uma tarefa offline, seu colega edita a mesma tarefa no servidor. Quando você se conecta, qual versão vence? Seu esquema precisa lidar com isso:

struct Tarefa {
    std::string id;
    std::string titulo;
    bool concluida;
    long criadoEm;
    long modificadoEm;
    bool sincronizado;
    std::string status;       // "pendente", "sincronizado", "conflito"
    std::string versaoLocal;  // Sua versão
    std::string versaoServidor; // Versão do servidor (se houver conflito)
};

Estruturando Seus Dados Localmente

Pense em sua estrutura de dados como uma tabela em um banco de dados local. Cada tarefa é uma linha, cada propriedade é uma coluna:

id	titulo	modificadoEm	status
uuid-123	Comprar leite	1699564800	pendente
uuid-456	Estudar C++	1699564900	sincronizado

O Fluxo de Sincronização

Aqui está como tudo funciona junto:

1. Criar localmente: Usuário cria uma tarefa → salva no banco local com status "pendente"
2. Detectar mudanças: Seu app verifica quais tarefas têm status "pendente"
3. Sincronizar: Quando há conexão, envia essas tarefas ao servidor
4. Atualizar status: Servidor responde com sucesso → muda status para "sincronizado"
5. Resolver conflitos: Se houver conflito, armazena ambas as versões para o usuário decidir

Dica Prática

Sempre adicione um campo modificadoEm com um timestamp. Isso é ouro puro para sincronização! Você pode comparar timestamps para saber qual versão é mais recente.