PWA offline, idempotência e limpeza local

Um dia grande no projeto cliente (NDA), com muitas frentes paralelas convergindo para a mesma pergunta: como deixar uma aplicação offline-first confiável o suficiente para uso real.

Foram muitas sessões em workspaces diferentes, mas o trabalho se agrupou em poucos temas.

Projeto cliente (NDA)

Offline, sync e idempotência

O eixo principal foi fortalecer o contrato entre frontend, backend, IndexedDB e fila offline. Revisei a idempotência de cadastros, a chave usada pelo frontend, o retry de operações pendentes e a relação entre dados locais e dados confirmados pelo servidor.

Também avancei na decisão de manter uma migration consolidada enquanto ainda não há carga real em produção. Nesse momento, faz mais sentido reduzir ruído de histórico e garantir que o estado inicial do banco esteja claro.

PWA e experiência mobile

Outra parte forte do dia foi o PWA. O app ganhou manifest mais rico, instalação guiada, wake lock, badging e ajustes de instalação em plataformas diferentes. Também revisei o header fixo no mobile, o comportamento do app quando instalado e pontos de lentidão percebidos durante uso como PWA.

A limpeza de dados locais entrou como ferramenta de suporte: um botão em Configurações para apagar IndexedDB quando o ambiente local fica inconsistente ou quando um teste precisa começar limpo.

Backend e domínio

No backend, consolidei logging com Pino, revisão de mocks de teste, idempotência e tratamento de dados sensíveis em logs. Também continuei separando conceitos que estavam misturados, como número sequencial de relatório e ordem de serviço digitada.

tgmarinho-ai-website

Revisei o post sobre idempotência em APIs, sistemas distribuídos e fluxos offline-first. O texto ficou mais preso ao problema real: retry não é o único risco, porque o usuário, a fila offline ou um webhook também podem tentar repetir uma operação já processada.

O dia foi sobre tirar ambiguidade: no banco, na fila, no PWA e no texto que explica por que isso importa.