Local-first e CRDTs: como criar apps offline com sincronização
Entenda como local-first e CRDTs permitem criar aplicativos rápidos, que funcionam offline, sincronizam dados e combinam alterações sem perdas.
Você abre um aplicativo no metrô, edita uma tarefa sem sinal e vê a mudança salva imediatamente.
Mais tarde, o celular se reconecta e combina essa edição com outra feita no notebook.
Nada fica bloqueado esperando o servidor responder.
Essa experiência é a promessa das aplicações local-first e CRDTs: os dados úteis ficam disponíveis no dispositivo, enquanto a rede serve para sincronizar cópias, colaborar e manter redundância.
A arquitetura pode entregar velocidade e funcionamento offline, mas não é uma solução automática para qualquer sistema.
Este guia explica armazenamento local, sincronização, conflitos, segurança, servidores de apoio e os cuidados necessários para adotar o modelo sem trocar uma dependência por outra.
O que significa local-first?
Local-first é uma abordagem em que a cópia disponível no dispositivo ocupa o centro da experiência.
Ler e alterar dados não depende de uma viagem de ida e volta até a nuvem.
A sincronização acontece quando a rede está disponível, mas a aplicação continua útil sem ela.
O termo foi consolidado pelo ensaio Local-first software, do Ink & Switch. O trabalho descreve ideais como resposta imediata, colaboração entre dispositivos, funcionamento sem rede, privacidade, longevidade e maior controle do usuário sobre os próprios dados.
Isso não significa abandonar a nuvem. Servidores ainda podem autenticar usuários, descobrir colaboradores, guardar cópias, encaminhar alterações e executar tarefas pesadas.
A diferença é que eles deixam de ser o único lugar capaz de tornar o aplicativo funcional.
Local-first, offline-first e cloud-first: qual é a diferença?
| Abordagem | Fonte operacional principal | Comportamento sem rede |
|---|---|---|
| Cloud-first | Servidor | Limitado ou indisponível |
| Offline-first | Cache ou fila local com sincronização posterior | Fluxos selecionados continuam |
| Local-first | Cópia local completa para o trabalho do usuário | Leitura e edição permanecem centrais |
Offline-first é uma estratégia de experiência: preparar o aplicativo para quedas de conexão.
Local-first vai além e influencia o modelo de dados, a colaboração e a autoridade sobre as cópias.
Uma aplicação pode ter páginas em cache e ainda depender do servidor para salvar qualquer edição.
As Progressive Web Apps oferecem recursos importantes para uso offline, mas PWA e local-first não são sinônimos.
Uma descreve capacidades da aplicação web; a outra descreve uma arquitetura centrada em dados locais.
O que são CRDTs?
CRDT é a sigla de Conflict-free Replicated Data Type, ou tipo de dado replicado livre de conflitos.
É uma estrutura criada para permitir alterações concorrentes em várias réplicas e combiná-las de forma determinística.
Segundo a introdução técnica do portal CRDT.tech, essas estruturas são usadas em sistemas com replicação otimista.
As cópias podem receber mudanças enquanto estão separadas e, depois de trocar todas as operações ou estados necessários, convergem para o mesmo resultado.
Existem CRDTs para contadores, conjuntos, mapas, sequências e documentos. Uma biblioteca pode combinar esses tipos para representar uma lista de tarefas, um quadro colaborativo ou um editor de texto.
O desenvolvedor não precisa inventar uma regra genérica de “última gravação vence” para cada pacote recebido.
Como um CRDT resolve alterações concorrentes
Imagine uma lista compartilhada. Ana adiciona uma tarefa no celular sem conexão, enquanto Bruno marca outra como concluída no notebook.
As duas alterações partem da mesma versão, mas afetam elementos diferentes.
Quando os dispositivos se encontram, o CRDT combina as mudanças de acordo com regras matemáticas que não dependem da ordem de chegada.
Receber o mesmo pacote novamente também não deve duplicar o efeito.
Depois que todas as réplicas conhecem o mesmo conjunto de mudanças, elas apresentam o mesmo estado.
- Cada alteração carrega identidade e causalidade suficientes para ser combinada.
- Pacotes podem chegar atrasados, repetidos ou em ordens diferentes.
- O merge preserva mudanças compatíveis feitas em paralelo.
- A convergência ocorre sem eleger uma réplica como vencedora.
CRDT não elimina conflitos de negócio
“Livre de conflitos” não quer dizer que toda decisão humana terá um resultado correto.
Um CRDT consegue convergir tecnicamente, mas não sabe se duas pessoas reservaram o último assento, alteraram o mesmo preço ou aprovaram despesas incompatíveis.
Esses são conflitos semânticos. Eles exigem regras de domínio, validação no servidor, interface para revisão ou operações que dependem de coordenação.
O tipo de dado evita corrupção causada pela concorrência; ele não substitui as invariantes do negócio.
Arquitetura de uma aplicação local-first
Uma implementação típica separa interface, banco local, mecanismo de mudanças, transporte e serviços de apoio.
Essa divisão permite que a tela reaja imediatamente à cópia local enquanto a sincronização trabalha em segundo plano.
- Interface: lê e grava localmente, sem esperar a rede para cada ação.
- Persistência: mantém documentos e metadados no dispositivo.
- Motor de merge: registra alterações e produz um estado convergente.
- Transporte: troca pacotes por WebSocket, HTTP, rede local ou outro canal.
- Serviços de apoio: cuidam de identidade, descoberta, backup, políticas e entrega para dispositivos desconectados.
A documentação do Automerge mostra armazenamento local e sincronização usando IndexedDB e BroadcastChannel.
É um exemplo de como persistência e rede podem ser adaptadores independentes do documento replicado.
O que acontece quando o usuário fica offline
- O usuário realiza uma ação, como editar uma nota.
- A aplicação valida o que pode ser validado no dispositivo.
- A mudança é aplicada e persistida localmente.
- A interface confirma a edição imediatamente e indica que a sincronização está pendente.
- Ao recuperar conexão, o dispositivo troca apenas as mudanças que faltam.
- O motor combina alterações remotas e atualiza a interface.
O estado da sincronização precisa ser visível. “Salvo neste dispositivo”, “sincronizando” e “requer atenção” são mensagens diferentes.
Esconder tudo atrás de um indicador genérico pode fazer o usuário fechar o aparelho antes de uma alteração importante alcançar outra réplica.
Armazenamento local em aplicações web
No navegador, Cache Storage e IndexedDB resolvem problemas diferentes. O service worker pode manter HTML, CSS, JavaScript e respostas necessárias para abrir o aplicativo.
A IndexedDB persiste dados estruturados e oferece consultas mesmo sem conexão.
A documentação da MDN sobre operação offline em PWAs mostra que estratégias de cache variam conforme o recurso. Cache-first favorece velocidade, enquanto network-first favorece atualização.
Nenhuma delas, isoladamente, resolve merge concorrente de dados do usuário.
Também é preciso lidar com cotas, limpeza pelo navegador, múltiplas abas, migrações de esquema e dispositivos compartilhados.
Dados críticos não devem existir em apenas uma cópia local; sincronização e exportação continuam essenciais.
Qual é o papel do servidor?
O servidor pode guardar uma réplica sempre disponível. Isso permite que o celular envie mudanças agora e o notebook as receba horas depois, sem que os dois estejam online ao mesmo tempo.
Ele também pode limitar acesso, encaminhar pacotes e manter backups.
Uma API REST ainda pode atender identidade, pagamentos, pesquisa global e operações coordenadas. Para dados replicados, o transporte deve aceitar retomada, reenvio e pacotes fora de ordem.
O servidor de sincronização não precisa ser tratado como a única versão verdadeira do documento.
Bancos gerenciados continuam úteis para contas, permissões, índices globais e cópias de segurança.
Ao comparar bancos de dados em nuvem, verifique limites de conexão, regiões, recuperação e custo de tráfego, não apenas o plano gratuito.
CRDT vs. sincronização tradicional e Operational Transformation
Na sincronização tradicional, o cliente envia comandos ao servidor e recebe uma versão oficial.
É simples quando a conexão é constante e o servidor pode ordenar todas as operações. Para modo offline, surgem filas, versões e políticas como “última gravação vence”, que podem descartar trabalho.
Operational Transformation transforma operações concorrentes em relação umas às outras e é conhecida por editores colaborativos.
CRDTs incorporam propriedades de convergência ao modelo de dados e podem funcionar com topologias descentralizadas.
Nenhuma opção é universalmente superior: maturidade da biblioteca, tamanho do histórico, requisitos de servidor e comportamento esperado devem orientar a escolha.
Change Data Capture também replica mudanças, mas normalmente captura alterações de um banco central para alimentar outros sistemas.
CRDTs tratam réplicas que podem ser editadas concorrentemente; são problemas próximos, porém diferentes.
Segurança, autenticação e controle de acesso
Guardar dados no dispositivo amplia a disponibilidade, mas também amplia a superfície de exposição.
Um aparelho perdido, um perfil de navegador compartilhado ou um script malicioso pode acessar informações que antes existiam apenas no servidor.
- Minimize o que precisa permanecer local e defina prazos de retenção.
- Proteja chaves com recursos seguros da plataforma quando disponíveis.
- Autorize cada documento e valide permissões também no recebimento.
- Planeje revogação, remoção de dispositivos e rotação de credenciais.
- Considere exportação, exclusão e consentimento desde o modelo inicial.
As mesmas práticas de APIs seguras e escaláveis continuam relevantes para autenticação, limites, auditoria e validação.
Além disso, a equipe precisa avaliar os controles de segurança na nuvem usados pelas réplicas de apoio.
Criptografia ponta a ponta: benefício e desafio
Com criptografia ponta a ponta, o servidor pode transportar e armazenar pacotes sem ler o conteúdo.
Isso melhora a privacidade, mas transfere responsabilidades para os clientes: distribuição de chaves, convite de colaboradores, recuperação de conta e revogação tornam-se mais complexos.
Revogar um usuário não apaga cópias que ele já recebeu. O sistema pode impedir novas atualizações e rotacionar chaves, mas não controlar um dispositivo fora de sua posse.
A promessa ao usuário deve refletir esse limite.
Modelagem, histórico e exclusões
CRDTs mantêm metadados para entender mudanças concorrentes. Em documentos muito ativos, histórico, identificadores e marcas de exclusão podem crescer.
Bibliotecas aplicam compactação e coleta de lixo, mas a equipe precisa medir o comportamento com dados reais.
Excluir é mais difícil do que remover uma linha: uma réplica antiga pode reaparecer meses depois e tentar reenviar algo.
O protocolo deve distinguir uma exclusão válida de uma cópia desatualizada. Migrações de esquema também precisam aceitar clientes que ficaram offline durante várias versões.
Modele documentos com limites claros. Um único CRDT contendo toda a conta pode gerar sincronizações e permissões pesadas.
Documentos menores facilitam carregamento sob demanda e compartilhamento seletivo, embora aumentem o trabalho de referências entre eles.
Desempenho e observabilidade da sincronização
Resposta local rápida não garante sincronização saudável. Monitore tamanho dos documentos, volume de mudanças pendentes, tempo para convergir, bytes transferidos, falhas de merge, uso de armazenamento e idade da última cópia confirmada pelo servidor.
Teste redes lentas, quedas durante o envio, reentregas, relógios incorretos, múltiplas abas e clientes antigos.
A interface deve permanecer responsiva durante compactação e merge; operações pesadas podem ser movidas para uma thread de trabalho quando a plataforma permitir.
Quando usar local-first e CRDTs
- Editores, notas, tarefas e quadros colaborativos.
- Aplicativos de campo com conexão instável.
- Ferramentas criativas nas quais baixa latência protege o fluxo de trabalho.
- Produtos usados em vários dispositivos pelo mesmo usuário.
- Sistemas nos quais exportação, longevidade e posse dos dados são diferenciais.
O ganho é maior quando o usuário cria conteúdo e não pode perder trabalho.
Começar com um único tipo de documento permite aprender sobre sincronização e interface antes de transformar toda a plataforma.
Quando uma arquitetura centralizada é melhor
Operações que exigem uma verdade única imediata, como saldo bancário, estoque escasso, leilão e autorização crítica, geralmente precisam de coordenação central.
Permitir decisões concorrentes e reconciliá-las depois pode violar regras que não admitem duplicidade.
Local-first também pode ser excesso para um sistema interno sempre conectado, com poucos usuários e formulários simples.
A complexidade aparece em migração, observabilidade, segurança e suporte a versões antigas. Um cache local com fila de comandos pode resolver o problema por um custo menor.
Plano de implementação em oito etapas
- Escolha um fluxo em que trabalhar offline tenha valor mensurável.
- Defina quais dados pertencem ao documento local e quais exigem autoridade central.
- Modele identidade, causalidade, exclusão e permissões antes da interface.
- Selecione uma biblioteca madura e faça um protótipo com concorrência real.
- Implemente persistência local e uma indicação clara do estado da sincronização.
- Adicione o servidor de apoio com autenticação e privilégios mínimos.
- Teste offline prolongado, dispositivos antigos, duplicação e falhas parciais.
- Meça crescimento, convergência e recuperação antes de ampliar o modelo.
Perguntas frequentes
Todo aplicativo offline precisa de CRDT?
Não. Se apenas um dispositivo edita os dados ou se o servidor pode rejeitar alterações antigas, uma fila local com versões pode ser suficiente. CRDT ganha valor quando várias réplicas editam concorrentemente.
CRDT dispensa um servidor?
Não necessariamente. O merge pode ser descentralizado, mas um servidor facilita descoberta, entrega assíncrona, backup, autenticação e recuperação. Ele deixa de ser requisito para cada edição local.
CRDT é um banco de dados?
CRDT é um modelo de estrutura replicada e merge. Bibliotecas podem incluir persistência e sincronização, mas índices, consultas, backup, controle de acesso e operação continuam sendo decisões da arquitetura.
Duas pessoas podem editar o mesmo texto offline?
Sim. CRDTs de sequência conseguem combinar inserções e exclusões concorrentes. Ainda assim, a interface pode precisar mostrar autoria e ajudar quando o texto resultante estiver correto tecnicamente, mas estranho semanticamente.
É possível usar local-first em uma PWA?
Sim. Service worker, Cache Storage e IndexedDB fornecem a base web para abrir a interface e persistir dados. Um motor de sincronização acrescenta histórico, troca de mudanças e convergência.
Como testar falhas de sincronização?
Simule dispositivos que editam separados, pacotes repetidos, ordem invertida, interrupção no meio do envio e clientes desatualizados. Ao final, todas as réplicas devem convergir sem perder alterações válidas.
Conclusão
Aplicações local-first colocam a resposta e os dados do usuário no dispositivo, usando a rede para colaboração e redundância.
CRDTs tornam possível combinar mudanças concorrentes sem depender de uma ordem global ou descartar silenciosamente uma edição.
O modelo funciona melhor quando o produto aceita convergência posterior e valoriza trabalho offline.
Comece por um documento limitado, deixe o estado da sincronização visível e teste situações adversas.
A experiência só será confiável quando armazenamento, merge, segurança e recuperação forem tratados como partes do mesmo sistema.