Che cos'è una PWA (Progressive Web App)?

Una PWA è una web app che usa service worker, un manifest e HTTPS per essere installabile, funzionare offline e ricevere notifiche push. Il termine, coniato da Alex Russell e Frances Berriman nel 2015, indica ciò che colma la distanza tra un sito web e un’app installata senza uscire dal web: un’unica codebase, un’icona nella schermata iniziale, una finestra autonoma e uno schermo che continua a funzionare quando il treno entra in galleria. La prospettiva che questo glossario aggiunge, e che le guide frontend saltano: una PWA resta un client – il service worker mette in cache, ma la fonte di verità è il backend.

Punti chiave

I tre pilastri, e il backend dietro di loro

// 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.
// saveEventually() stores the write offline and sends it when back online:
const note = new Parse.Object('Note').set('text', draft);
await note.saveEventually(); // 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.

Un service worker è uno script in background che si colloca tra l’app e la rete come un proxy – mette in cache la shell e la serve offline; un web app manifest è un file di metadati JSON (nome, icone, display: standalone, URL di avvio) che rende l’app installabile; e HTTPS è obbligatorio, perché i service worker si rifiutano di girare fuori da un contesto sicuro. Questi tre elementi costituiscono la facciata dell’app. Il save() nelle schede di codice mostra ciò che c’è dietro: la cache è uno specchio, e quando la rete torna la scrittura si sincronizza con il backend autorevole.

Come una PWA serve una pagina offline

Strategie di cache offline

La decisione si prende risorsa per risorsa, non a livello di app: la shell vuole cache-first per caricamenti istantanei; i dati vivi dell’utente vogliono network-first per la freschezza; un feed può accontentarsi di stale-while-revalidate per sembrare istantaneo e correggersi da solo. Qualunque sia la strategia scelta, la cache è un buffer di lettura/scrittura sopra l’API – le scritture offline vanno in coda localmente e si riconciliano alla riconnessione, la stessa disciplina di recupero che ogni client offline-first richiede.

Da dove arrivano davvero le notifiche push

Il meccanismo che quasi nessun glossario spiega, e il motivo per cui una PWA ha bisogno di un backend anche solo per notificare. Il client si limita a sottoscrivere: chiede il permesso e riceve un endpoint di sottoscrizione. L’invio è un lavoro del server – il backend → il servizio push del browser → l’evento push del service worker → una notifica visualizzata. Il service worker può svegliarsi per mostrarla con l’app chiusa, ma non arriva nulla se un backend non l’ha inviata: “le PWA hanno il push” è quindi solo metà di una feature senza la metà server. L’articolo sulle notifiche push copre la catena di consegna; il punto qui è che web push e push nativo terminano entrambi nel proprio codice che decide di inviare.

PWA vs. app nativa

L’asimmetria onesta sta nell’ultima riga: iOS è il punto debole delle PWA – installazione solo dal menu Condividi, nessun install prompt automatico, push solo una volta installata e solo sulle versioni recenti, sincronizzazione in background incompleta. Su Android e desktop la distanza dal nativo è piccola; su iOS è il fattore decisivo per molti prodotti.

Casi d’uso comuni

• Contenuti e commercio – copertura, SEO e bassa frizione di installazione battono il download da uno store nel raggiungere nuovi utenti.
• Strumenti interni – app installabili e tolleranti all’offline per utenti noti, senza distribuzione tramite store.
• App sul campo offline-first – raccogliere dati senza segnale, sincronizzare quando torna; il pattern della cache come buffer.
• Copertura multipiattaforma a basso costo – un’unica codebase web per coprire piattaforme che una build nativa triplicherebbe.
• A fianco di un’app nativa – lo stesso backend serve una PWA per la copertura e un’app nativa per la profondità.

Conviene costruire una PWA? Matrice decisionale

Limiti e trade-off

• iOS fissa il tetto. Installazione manuale dal menu Condividi, push condizionato e lacune nella sincronizzazione in background fanno di iOS il vincolo che più spesso decide tra PWA e nativo.
• L’accesso all’hardware è parziale. Bluetooth, NFC, contatti e API avanzate della fotocamera sono limitati o assenti a seconda del sistema operativo – le app molto legate al dispositivo vogliono ancora il nativo.
• La cache non è il database. Trattare la cache del service worker come fonte di verità apre la porta a scritture perse e conflitti su dati non aggiornati; è un buffer sopra il backend autorevole.
• Il push è metà client, metà server. Sottoscrivere è facile; una PWA ha comunque bisogno di un backend per inviare, quindi “offline e push” è una feature backend con un distintivo frontend.
• La visibilità nelle ricerche è un’arma a doppio taglio. Nessun filtro dello store significa anche nessuna vetrina dello store; si scambiano curatela e cerimonia di installazione con un URL.

Le PWA su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. È la metà backend della feature che i pilastri frontend si limitano a completare: il service worker mette in cache la shell, ma Back4app è la fonte di verità di cui quella cache è lo specchio – utenti autenticati, dati sincronizzati che riconciliano le scritture offline alla riconnessione, e il server che invia davvero il web push a cui una PWA può solo sottoscriversi. Poiché un solo backend serve allo stesso modo una PWA, una web app classica e un’app nativa attraverso SDK per piattaforma, la copertura multipiattaforma che una PWA promette sul frontend trova il suo corrispettivo sul backend, scritto una volta sola – il client mette in cache, la piattaforma ricorda, e le due metà di “installabile, offline e push” finalmente si incontrano.