Arquitectura local para aplicações Web Corporativas: Além de Fallbacks offline

Aplicações web tradicionais dependem do pressuposto de que uma conexão de rede estável e de baixa latência está sempre disponível. A maioria dos softwares de linha de negócio trata um banco de dados de nuvem central como a única fonte de verdade, direcionando mutações e pesquisas através do REST ou GraphQL endpoints. Quando picos de latência ou quedas de conectividade (como em armazéns, inspeções de serviço de campo ou hangars de aeronaves), os usuários encontram spinners de carregamento, formulários bloqueados e atualizações otimistas quebradas.

A arquitetura local primeiro muda este modelo, tratando a loja de dados local do cliente como a fonte primária da verdade em vez de tratar o navegador como um cliente fino para o estado remoto. Leituras e mutações são executadas contra um banco de dados em processo localmente em menos de 1ms, enquanto um motor de sincronização de fundo se reconcilia bidirecionalmente com o servidor.

O conceito decorre do trabalho de pesquisa da Ink & Switch 2019 *"Software Local"*Entre 2024 e 2026, a adoção de empresas passou de protótipos experimentais para implantações de produção. O acesso padronizado ao sistema de arquivos de navegador, os tempos de execução relacionais WebAssembly e os protocolos de sincronização especializados agora permitem que as equipes executem sistemas web distribuídos sem abrir mão de garantias ou segurança transacionais.

Em Lidex, construímos software personalizado e modernizamos sistemas empresariais onde o tempo de inatividade induzido pela rede interrompe as operações do núcleo. Abaixo está uma visão geral de como os sistemas locais de primeiro funcionamento sob o capô, seus trade-offs práticos, e padrões de implementação para a produção.

Por que o backback offline falha os fluxos de trabalho corporativos (e como o local-como-primário corrige)

A maioria das aplicações web tenta lidar com conectividade intermitente usando caches de trabalhadores de serviço e otimista UI actualizações. Quando alguém envia uma fatura ou muda a contagem do inventário, o cliente atualiza sua variável de estado local, assume sucesso e envia uma solicitação assíncrona pela rede. Se essa requisição falhar, o aplicativo mostra uma torrada de erro, retorna a alteração ou empurra a mutação para uma fila de indexedDB ad hoc.

Em ambientes transacionais complexos, este padrão quebra rapidamente:

• Inconsistência do Estado: Se um usuário completar três passos dependentes enquanto estiver offline (como criar um relatório de inspeção, anexar defeitos de itens de linha e atribuir tarefas), o retorno do passo dois deixa o estado restante fora de sincronia ou corrompido.
• Latência da rede: Esperar de 100 a 300ms para viagens de rede entre atualizações de visualização retarda a transferência do operador em interfaces densas como os sistemas ponto de venda ou ERP.
• Tratamento complexo de erros: O código front-end acaba sobrecarregado com filas de mutação personalizadas, lógica de repetição, backoffs exponenciais e pedidos de conflito através de formulários.

Com um design local-como-primário, lê e escreve executar síncronamente contra memória local ou disco. Como o aplicativo escreve diretamente em um banco de dados incorporado, a persistência é imediata e atômica. As mutações não falham simplesmente porque a rede cai. A rede serve como uma camada de transporte assíncrono para sincronização em vez de uma dependência de execução de bloqueio.

Traditional Architecture:
[Client UI] ---> Network (100-300ms) ---> [API Gateway] ---> [Cloud Database]
                      (Network drops = System stalls)

Local-First Architecture:
[Client UI] ---> Local Embedded DB (<1ms)
                      |
             Background Sync Engine
                      |
             [Central Database & Sync Server]

Substratos de armazenamento de navegadores: OPFS, WASM SQLite e PGlite

A execução de um motor relacional incorporado dentro do navegador foi uma vez restrita pelo IndexedDB. IndexedDB lida com dados básicos de valor chave, mas seu API é desajeitado, seu suporte à transação é limitado, e sua serialização baseada em cursor torna a consulta de milhares de registros lentos.

Implementações modernas usam o Origin Private File System (OPFS), suportado em versões modernas de Chromium, Safari e Firefox. OPFS dá acesso a sistemas de arquivos privados de aplicações web com rápido desempenho de leitura e gravação, permitindo que bancos de dados compilados com WebAssembly executem operações de sistemas de arquivos nativos dentro de Web Workers.

Dois tempos de execução são comuns na produção:

1. SQLite compilado para WebAssembly (wa-sqlite ou SQLite oficial WASM): Usando OPFS para persistência, WASM SQLite fornece transações, índices e SQL consultas diretamente sobre o cliente através de centenas de milhares de registros.
2. PGlite (ElectricSQL): Lançado em 2024 e mantido através de revisões principais subsequentes, pacotes PGlite Postgres em um pacote WebAssembly de aproximadamente 3MB comprimido. Ele é executado dentro dos trabalhadores do navegador, Bun, ou Node.js, oferta PostgreSQL compatibilidade dialeto. Os clientes podem executar consultas parametrizadas, junções relacionais e busca de vetores do lado do cliente usando extensões pgvector incorporadas.

Gestão de quotas e salvaguardas de despejo

Os dispositivos clientes têm armazenamento finito. Enquanto os navegadores modernos permitem que aplicativos requeiram armazenamento persistente via navigator.storage.persist() e usem até 60% a 80% do espaço em disco disponível, o navegador ou sistema operacional host ainda pode despejar dados se o espaço em disco for muito baixo.

Os sistemas de produção local-primeiro não devem tratar o armazenamento do cliente como armazenamento de arquivo permanente. A aplicação requer um backup do lado do servidor autorizado emparelhado com uma estratégia de despejo menos recente (LRU) usada para podar registros antigos, preservando o conjunto de trabalho ativo localmente.

O motor de sincronização: por que os sistemas empresariais foram além dos CRDTs puros

As primeiras pesquisas locais focaram fortemente em tipos de dados replicados livres de conflitos (CRDTs). CRDTs baseados em estado e em operação permitem que múltiplos nós atualizem dados simultaneamente sem um coordenador central, resolvendo ramos divergentes deterministicamente.

Bibliotecas como Yjs, Automerge (nomeadamente depois de 2025 Rust a reescrita do núcleo, que reduziu significativamente a memória do documento, e Loro funciona bem para ferramentas colaborativas de texto rico e tela como Notion, Figma ou Excalidraw. No entanto, CRDTs puros introduzem grandes atritos quando aplicados em aplicações de negócios relacionais como ERP, CRM e sistemas de inventário:

• Tombos e crescimento da memória: Rastreando exclusões e atualizações frequentes em dados transacionais cria lápides acima que balões de uso de memória.
• Restrições relacionais: Os sistemas de negócios dependem de chaves estrangeiras e invariantes multi-record. Os CRDT puros de pares não podem facilmente impor restrições de tabela cruzada sem uma autoridade coordenadora.

Devido a essas limitações, equipes que constroem software de negócios têm adotado amplamente os motores de sincronia reconciliados com servidor que conectam um banco de dados central (tipicamente Postgres) com réplicas de clientes incorporados locais.

Frameworks de sincronização de produção

• Zero (Rocicorp): Usa a reconciliação do servidor inspirada em arquiteturas de jogos multiplayer. Um processo 'zero-cache' fica na frente dos Postgres e sincroniza assinaturas de consultas filtradas para motores de consulta do lado do cliente.
• ElectricSQL (Arquitectura de Formas): Afastado de CRDTs cliente puro para um modelo de streaming HTTP chamado Shapes. Os fluxos de servidor parametrizados, subconjuntos cacheáveis de tabelas Postgres sobre HTTP ou Eventos de Envio de Servidor (SSE) em instâncias locais SQLite ou PGlite.
• PowerSync: Um serviço que sincroniza as bases de dados (Postgres, MySQL, MongoDB) diretamente com bases de dados SQLite locais através da web, Flutter, React Native, e Kotlin Clientes multiplataforma.

Corte de dados e segurança no limite da replicação

Bancos de dados empresariais armazenam rotineiramente dezenas ou centenas de gigabytes em milhões de linhas. Os clientes não podem copiar toda a base de dados localmente, nem devem ter acesso livre a dados fora do seu âmbito. As configurações de produção gerenciam isso através da replicação parcial e limites de autorização rigorosos.

Corte dinâmico de dados

Os motores modernos de sincronização estabelecem assinaturas filtradas em vez de sincronizar o banco de dados completo. Os limites de sincronização se adaptam com base na visão e papel ativo do usuário.

Por exemplo, no benchmark "Gigabugs" da Rociorp (que avalia consultas em um conjunto de dados de 1,2 milhões de linhas), o cliente sincroniza e indexa apenas visualizações ativas e registros recentemente visualizados. Isto mantém UI Interações sub-segundo, mantendo atualizações locais reativas.

Mudando a autorização para a camada de replicação

Em uma arquitetura tradicional REST, a autorização acontece por pedido no API camada:

// Traditional: Auth validated at the API layer
app.get('/api/invoices/:id', authenticateUser, async (req, res) => {
  const invoice = await db.invoices.findById(req.params.id);
  if (invoice.organizationId !== req.user.orgId) {
    return res.status(403).send('Forbidden');
  }
  return res.json(invoice);
});

Porque um primeiro cliente local corre SQL ou expressões construtor de consultas diretamente contra suas tabelas locais, registros não autorizados nunca devem chegar ao navegador em primeiro lugar.

Isso requer mover a autorização diretamente para o fluxo de replicação. Protocolos modernos de sincronização avaliam políticas de segurança de nível de linha (RLS) ou regras declarativas antes de transmitir linhas para o cliente (por exemplo, através de regras de sincronização PowerSync ou manifestos de permissão zero):

• O cliente abre um fluxo de sincronização com credenciais de sessão autenticadas, como um JWT verificado.
• O motor de replicação avalia políticas RLS ou regras de sincronização antes de transmitir registros.
• Apenas linhas autorizadas chegam ao banco de dados do cliente, mantendo dados não autorizados fora do dispositivo inteiramente.

Evolução do esquema e deriva de multi-versão

Em aplicativos web padrão, atualizações front-end e migrações de banco de dados implantar em lockstep, e os clientes adotam o novo esquema ao recarregar.

Nos primeiros sistemas locais, os usuários podem manter as abas abertas por dias ou trabalhar off-line por semanas enquanto as migrações da infraestrutura ocorrem. Se um cliente tentar sincronizar mutações com base num esquema desactualizado com uma infra- estrutura modificada, a replicação ingénua irá falhar.

Manipulação esquema deriva confiável requer três padrões:

1. Migrações de servidores aditivos

Bases de dados centrais autoritativas mantêm a compatibilidade inversa. As colunas não são renomeadas ou largadas sem um período de depreciação faseado.

2. Gestão de migração do lado do cliente

Na inicialização, a instância local SQLite ou PGlite executa scripts de migração local em sequência antes de iniciar o motor de sincronização.

3. Transformação bidirecional através de lentes de esquema

Para a deriva multi-versão, as arquiteturas se baseiam na pesquisa da Ink & Switch Projeto CambriaLentes de esquema definem transformações bidirecionais entre versões de esquema:

Server Schema v5 <---> [Lens v4-v5] <---> [Lens v3-v4] <---> Client Schema v3

Essas lentes traduzem operações de leitura e gravação entre modelos de clientes mais antigos (como Schema v3) e o modelo de infraestrutura (como Schema v5) sem corromper dados simultâneos.

Implementação dos primeiros sistemas locais

A mudança para uma arquitetura local-primeira muda fundamentalmente como as aplicações lidam com estado, replicação e governança de dados. Fornece tempos de resposta instantâneos e mantém fluxos de trabalho críticos operacionais independentemente da volatilidade da rede.

Em Lidex, projetamos e modernizamos software corporativo onde as interrupções de rede não podem comprometer as operações – alavancando tempos de execução WASM, persistência OPFS e motores de sincronização de servidor para construir aplicativos confiáveis e de alto desempenho.