Local-first pode significar três coisas diferentes, e cada uma exige uma arquitetura

O autor do texto, que desenvolve o Hologram, separa três sentidos para local-first: funcionar sem conexão, ter interface rápida e otimista, e o usuário ser dono dos dados. A definição que ele adota é a segunda, junto com a primeira: a UI nunca fica bloqueada pela rede. O app lê de uma cópia local, as escritas caem nela na hora e a sincronização roda em segundo plano. Nessa leitura, ficar sem rede é só o caso mais lento possível de rede.

O termo vem de um ensaio de 2019 de Martin Kleppmann, Adam Wiggins, Peter van Hardenberg e Mark McGranaghan, do Ink & Switch, que prioriza a propriedade dos dados. O problema é o conflito. CRDTs garantem que as cópias convirjam, mas não conhecem regras de negócio: dois passageiros no assento 14C convergem sem erro. Por isso a maioria das ferramentas recoloca um servidor com a palavra final. O texto cita que o Zero diz em sua documentação que não é local-first por ter servidor autoritativo, enquanto o Jazz, que começou como framework CRDT e migrou para um modelo com servidor no comando, ainda usa o termo. Para quem usa TanStack Query, o artigo compara o ciclo manual de update otimista (cancelar fetches, snapshot, cache, rollback, refetch) com o TanStack DB, que trata coleções locais e live queries. No Hologram, framework full-stack em Elixir com a parte do navegador compilada para JavaScript, o servidor segue aplicando permissões e regras, e o plano inclui criptografia de ponta a ponta para entidades ou atributos escolhidos.

Em 8 de maio de 2026, o CEVIU noticiou "A Arquitetura do Desenvolvimento Web Local-First", que descrevia o modelo como dados guardados primariamente no dispositivo, e não em servidor central. A notícia atual refina isso: o texto mostra que, na prática, muitas ferramentas mantêm um servidor autoritativo, e que "local-first" cobre propostas diferentes. Em 7 de outubro de 2026, o CEVIU publicou "Desvendando o Frontend: Uma Arquitetura Unificada para Navegação, Conteúdo e Otimizações Client-Side", que citava estados otimistas como um dos pilares do lado do cliente. Aqui, o mesmo tema aparece como ponto de partida para um banco local com sincronização.

Para quem decide arquitetura, a leitura é que a pergunta útil não é se a ferramenta é local-first, e sim qual das três promessas ela entrega. Se o seu problema é spinner e update otimista escrito à mão, um servidor com a palavra final resolve. Se o requisito é propriedade dos dados, o desenho muda e as regras de negócio ficam mais difíceis de aplicar.