O que é uma PWA (Progressive Web App)?

Uma PWA é um app web que usa service workers, manifest e HTTPS para ser instalável, funcionar offline e receber notificações push. Cunhado por Alex Russell e Frances Berriman em 2015, o termo fecha a distância entre um site e um app instalado sem sair da web: um único código-fonte, ícone na tela inicial, janela própria e uma tela que continua funcionando quando o trem entra no túnel. O ângulo que este glossário acrescenta — e que os guias de frontend pulam: uma PWA continua sendo um cliente — o service worker faz cache, mas o seu backend é a fonte da verdade.

Principais pontos

Os três pilares, e o backend por trás deles

// JavaScript — the PWA's three pillars + the backend behind them
// 1 · Service worker: caches the shell, buffers writes when offline
navigator.serviceWorker.register('/sw.js');

// 2 · Manifest (public/manifest.json) makes it installable:
//    { "name": "Notes", "display": "standalone", "start_url": "/", "icons": [...] }

// 3 · HTTPS is required — service workers refuse to run otherwise.

// The catch: the SW cache is a MIRROR, not the source of truth.
// When back online, queued writes sync to the real backend:
const note = new Parse.Object('Note').set('text', draft);
await note.save(); // the BaaS is authoritative; the cache was a buffer

// Flutter / Dart — Back4app Flutter SDK (Flutter web compiles to a PWA)
// The service worker caches the app shell; data still lives on the backend.
final note = ParseObject('Note')..set('text', draft);
await note.save();
// Offline-first pattern: write locally, queue, and sync when connectivity
// returns — the API/BaaS is the source of truth, the cache is a local mirror.
// Push notifications need a BACKEND to send them; the client only subscribes.

// Swift — a native shell can host a PWA/WebView; the backend is shared
// The point of parity: whatever the client (PWA, native, web), the
// source of truth is the same backend API.
var note = Note()
note.text = draft
_ = try await note.save()
// Offline-first: cache locally, sync when online — the API is authoritative.
// Web push (PWA) and native push (APNs) both need a backend to SEND them.

// Kotlin — a native shell can host a PWA/WebView; the backend is shared
// The point of parity: whatever the client (PWA, native, web), the
// source of truth is the same backend API.
val note = ParseObject("Note")
note.put("text", draft)
note.save()
// Offline-first: cache locally, sync when online — the API is authoritative.
// Web push (PWA) and native push (APNs/FCM) both need a backend to SEND them.

Um service worker é um script em segundo plano que fica entre o app e a rede como um proxy — ele cacheia o shell e o serve offline; um web app manifest é o arquivo de metadados JSON (nome, ícones, display: standalone, URL inicial) que torna o app instalável; e HTTPS é obrigatório, porque service workers se recusam a rodar fora de um contexto seguro. Esses três fazem a frente do app. O save() nas abas de código mostra o que fica atrás dela: o cache é um espelho, e quando a rede volta, a escrita sincroniza com o backend autoritativo.

Como uma PWA serve uma página offline

Estratégias de cache offline

A decisão é por recurso, não por app: o shell do app quer cache-first para carregar na hora; os dados vivos do usuário querem network-first para frescor; um feed aceita stale-while-revalidate para parecer instantâneo e se corrigir sozinho. Seja qual for a escolha, o cache é um buffer de leitura/escrita sobre a API — escritas offline entram na fila local e se reconciliam ao reconectar, a mesma disciplina de catch-up que qualquer cliente offline-first precisa ter.

De onde as notificações push realmente vêm

O mecanismo que quase nenhum glossário explica, e o motivo pelo qual uma PWA precisa de um backend até para notificar. O cliente apenas se inscreve: pede permissão e recebe um endpoint de assinatura. Enviar é trabalho de servidor — seu backend → o serviço de push do navegador → o evento push do service worker → uma notificação exibida. O service worker pode acordar para exibi-la com o app fechado, mas nada chega se um backend não tiver enviado — e é por isso que “PWA tem push” é só metade de uma funcionalidade sem a metade servidor. O verbete de notificações push cobre a cadeia de entrega; o ponto aqui é que tanto o web push quanto o push nativo terminam no seu código decidindo enviar.

PWA vs. app nativo

A assimetria honesta mora na última linha: o iOS é onde as PWAs são mais fracas — instalação apenas pelo Safari, nenhum prompt de instalação automático, push só com o app instalado e só em versões recentes, e sincronização em segundo plano incompleta. No Android e no desktop a distância para o nativo é pequena; no iOS ela é o fator decisivo para muitos produtos.

Casos de uso comuns

• Conteúdo e comércio — alcance, SEO e baixa fricção de instalação valem mais que um download de loja para conquistar usuários novos.
• Ferramentas internas — apps instaláveis e tolerantes a offline para usuários conhecidos, sem distribuição por loja.
• Apps de campo offline-first — capture dados sem sinal, sincronize quando ele volta; o padrão do cache como buffer.
• Alcance multiplataforma com orçamento curto — um código-fonte web cobrindo plataformas que um build nativo triplicaria.
• Companheira de um app nativo — o mesmo backend servindo uma PWA para alcance e um app nativo para profundidade.

Você deveria construir uma PWA? Matriz de decisão

Limitações e trade-offs

• O iOS limita o teto. Instalação só pelo Safari, push restrito e lacunas de sincronização em segundo plano fazem do iOS a restrição que mais decide o duelo PWA-versus-nativo.
• Acesso ao hardware é parcial. Bluetooth, NFC, contatos e APIs avançadas de câmera são limitados ou ausentes dependendo do SO — apps que mergulham no dispositivo ainda pedem nativo.
• O cache não é o banco de dados. Tratar o cache do service worker como fonte da verdade convida escritas perdidas e conflitos de dados velhos; ele é um buffer sobre o backend autoritativo.
• Push é metade cliente, metade servidor. Inscrever-se é fácil; a PWA ainda precisa de um backend para enviar, então “offline e push” é uma funcionalidade de backend usando crachá de frontend.
• Descobribilidade corta dos dois lados. Sem o pedágio da loja também não há a vitrine da loja; você troca curadoria e cerimônia de instalação por uma URL.

PWAs no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Ele é a metade backend da funcionalidade que os pilares de frontend apenas completam: o service worker cacheia o shell, mas o Back4app é a fonte da verdade que o cache espelha — usuários autenticados, dados sincronizados reconciliando escritas offline ao reconectar, e o servidor que de fato envia o web push ao qual uma PWA só consegue se inscrever. Como um único backend serve igualmente uma PWA, um app web comum e um app nativo por meio de SDKs por plataforma, o alcance multiplataforma que a PWA promete no frontend encontra o alcance escreva-uma-vez no backend — o cliente cacheia, a plataforma lembra, e as duas metades de “instalável, offline e push” finalmente se encontram.