Local-First É Arquitetura, Não Recurso

A maioria dos apps é construída cloud-first: o servidor guarda a verdade, o cliente é uma visão fina e descartável sobre ela, e "suporte offline" — quando existe — é uma camada de cache parafusada depois pra disfarçar os momentos em que a rede não está lá. Essa ordem é exatamente ao contrário para um número crescente de aplicações, e isso aparece como bugs no exato momento em que a conectividade fica instável em vez de totalmente ausente.

O problema do cache como adendo

Parafusar suporte offline num app cloud-first geralmente significa: guardar em cache a última resposta conhecida do servidor, deixar o usuário visualizá-la, e enfileirar escritas pra reproduzir quando a conexão voltar. Isso funciona até dois clientes editarem o mesmo dado enquanto ambos estão offline — nesse momento, "reproduzir as escritas enfileiradas" vira "quem reconectar por último silenciosamente sobrescreve quem reconectou primeiro", e o app discretamente virou uma máquina de perder dados com um spinner por cima.

O que local-first realmente assume

Local-first inverte a premissa inicial: a cópia local do dado é a principal com a qual o usuário interage, ponto final, e a sincronização com um servidor (ou com outros dispositivos) é um processo em segundo plano que reconcilia estado — não a precondição pro app ser utilizável. Essa única inversão força decisões diferentes bem mais cedo no design:

• Resolução de conflito precisa ser um mecanismo real e desenhado — CRDTs, operational transforms, ou uma estratégia de merge explícita — não um efeito colateral incidental de "quem escreveu por último vence", porque edições offline concorrentes são o caso normal, não um caso extremo raro pra ignorar de ombros.
• O cliente precisa de um armazenamento local de dados de verdade, não só um cache de respostas, porque o app precisa ser totalmente funcional — leituras e escritas — com zero rede.
• Sincronização vira um problema de reconciliação em segundo plano, mais perto de replicação em sistemas distribuídos do que de um ciclo típico de requisição/resposta REST.

Por que isso está se espalhando além dos apps de anotação

A categoria mais associada a local-first ainda é pequena — editores colaborativos, ferramentas de anotação. Mas o problema de fundo (um app que precisa continuar totalmente utilizável e correto sob conectividade não confiável) se aplica muito mais amplamente do que isso: ferramentas de campo, sistemas de ponto de venda, qualquer coisa usada em algum lugar com conectividade instável por natureza. As ferramentas (bibliotecas de CRDT, motores de sincronização) amadureceram o suficiente pra que "local-first" esteja deixando de ser um tópico de pesquisa e virando uma opção arquitetural real, em vez de um projeto de pesquisa do zero que cada time precisa resolver sozinho.

A lição de verdade

Se o comportamento offline do seu app é "mostra um spinner de carregamento e um botão de tentar de novo", isso não é local-first, é cloud-first com uma rede pior. A distinção importa porque as duas produzem modos de falha genuinamente diferentes sob a mesma conexão ruim — uma degrada graciosamente, e a outra perde dados silenciosamente e diz que deu certo.