Offline-first: a interface não deveria depender de conseguir gravar um cache

No relato sobre o Efiwe, tutor de programação executado no navegador, uma tela em branco inicialmente atribuída a aparelhos baratos tinha outra causa: armazenamento cheio.[8] A inicialização aguardava a gravação de um manifesto no cache; quando essa operação falhava, a renderização não acontecia.[8] O caso é uma boa provocação para arquitetura: qual otimização recebeu, por acidente, poder de impedir a aplicação inteira?

O que muda para quem desenvolve

Apesar da menção a Android no título do artigo, a solução descrita é uma PWA.[8] Ela executa Python com Pyodide e SQL com sql.js, usando WebAssembly, e prepara esses runtimes sob demanda em Web Workers.[8] A estratégia busca evitar que o custo de inicialização bloqueie a primeira renderização.[8]

A correção do incidente separou a exibição da gravação opcional em cache, tratou a falha como não fatal e informou a perda de disponibilidade offline.[8] Minha leitura é que o desenho deve distinguir três coisas: conteúdo que já pode ser exibido, otimização que pode falhar e dado que só existe se uma gravação for confirmada.

Essa distinção impede uma conclusão perigosa. Não bloquear a tela por falha de cache é diferente de anunciar sucesso em uma operação crítica sem confirmação de persistência. O contrato de cada ação precisa dizer o que foi salvo, o que está pendente e o que foi perdido.

Como aplicar

Proponha uma matriz de cenários: armazenamento cheio, cache corrompido, primeira carga interrompida, endpoint lento e troca de perfil. Para cada um, descreva o que deve continuar funcionando e qual mensagem o usuário precisa receber.

No exercício de inicialização, simule falha da gravação opcional e verifique se o conteúdo disponível ainda aparece. Em outro cenário, interrompa uma gravação crítica e confira se a interface evita uma confirmação falsa. São critérios diferentes e devem permanecer separados.

O artigo relata migração de localStorage para IndexedDB com leitura dupla: consultar a base nova, recuperar o legado quando necessário, promover o dado e só então remover a chave antiga.[8] Para aplicar a ideia, inclua falha de promoção e conteúdo inválido na avaliação. Não apague a única cópia recuperável antes de comprovar a nova gravação.

Cuidados e limites

A aplicação passou a usar navigator.storage.estimate() para planejar cache completo ou carregamento gradual, mas a estimativa é aproximada e não garante sucesso de escrita.[8] Trate-a como auxílio de planejamento, nunca como substituto do tratamento de erro.

O relato também considera navigator.onLine apenas um sinal negativo rápido: conexão a uma interface não prova acesso ao endpoint.[8] Um experimento com portal cativo deve verificar essa diferença.

Quotas, expulsão de dados e armazenamento persistente continuam pouco previsíveis entre navegadores, segundo o autor.[8] Por isso, defina um pacote offline mínimo e comunique quando ele ainda não está pronto. Confiabilidade começa quando a aplicação consegue explicar seus próprios limites.

Fonte

[8] Fonte: InfoQ