Come aggiungere notifiche alla tua app: in-app, email e push

Per aggiungere notifiche a un'app web, inizia dalle notifiche in-app: una tabella delle notifiche nel database e un'icona a campanella che mostra gli elementi non letti. Aggiungi l'email per le cose che le persone devono sapere quando sono lontane, usando un fornitore di posta elettronica, e aggiungi le push web solo quando gli avvisi tempestivi contano davvero, perché richiedono un service worker, il permesso dell'utente e, su iPhone, l'app salvata nella schermata Home. Qualunque canale tu usi, crea ogni notifica in un unico punto sul server e lascia che siano gli utenti a scegliere cosa ricevere.

Questa guida confronta i canali, mostra un'architettura semplice e fornisce prompt da usare con un builder di app basato sull'IA.

I canali principali a confronto

La maggior parte delle app ha bisogno di notifiche in-app più email. Push e SMS valgono la pena quando il tempismo conta davvero, come un promemoria di prenotazione o un ordine pronto.

Come si incastra un sistema di notifiche

Mantienilo semplice e centralizzato:

1. Succede qualcosa. Viene pubblicato un commento, un pagamento fallisce, una prenotazione è domani.
2. Il tuo server chiama una sola funzione, per esempio notify(user, type, data).
3. Quella funzione controlla le preferenze dell'utente e scrive una riga nella tabella notifications (per la campanella).
4. Poi invia agli altri canali che l'utente ha attivato per quel tipo: email tramite il tuo fornitore, push tramite la Push API.
5. Il frontend mostra le notifiche non lette e le segna come lette quando vengono aperte.

Un unico punto di ingresso ti permette di aggiungere un canale, cambiare il testo o rispettare le preferenze senza cercare nel codice.

Cosa memorizzare

Una tabella delle notifiche di solito richiede: ID utente, tipo (per esempio comment_reply), un titolo e un testo brevi, un link alla pagina pertinente, la data di creazione e la data di lettura. Una tabella separata delle preferenze memorizza quali canali ogni utente vuole per ciascun tipo.

Mostrare le nuove notifiche

• Carica alla visualizzazione della pagina e fai polling ogni 30–60 secondi. È semplice e affidabile.
• Aggiornamenti in tempo reale con WebSocket o server-sent events danno un effetto immediato ma aggiungono parti in movimento. Parti dal polling, a meno che gli aggiornamenti istantanei non siano davvero importanti.

Notifiche email

L'email richiede un fornitore di invio e un dominio verificato; i dettagli sono in come inviare email dalla tua app. Per le notifiche in particolare:

• Invia dal server, mai con una chiave del fornitore nel browser.
• Raggruppa gli eventi frequenti. "3 nuovi commenti" in una sola email è meglio di tre email.
• Offri un riepilogo giornaliero o settimanale per le attività a bassa priorità.
• Includi un link per annullare l'iscrizione o per le preferenze nelle email non essenziali. Le regole sulle email di marketing cambiano da paese a paese; verifica quali si applicano a te.

Notifiche push web

Le push web permettono al tuo sito di inviare avvisi che appaiono come notifiche di un'app. Secondo la documentazione della Push API di MDN, funziona così:

1. Il tuo sito registra un service worker, uno script che il browser può eseguire in background.
2. Dopo che l'utente ha acconsentito, il service worker si iscrive tramite PushManager.subscribe(). Il browser restituisce una sottoscrizione con un endpoint e delle chiavi di cifratura.
3. Il tuo server memorizza quella sottoscrizione e, quando succede qualcosa, invia un messaggio all'endpoint, di solito firmato con chiavi VAPID (una coppia di chiavi che identifica il tuo server).
4. Il browser avvia il tuo service worker, che mostra la notifica anche se la tua pagina non è aperta.

MDN fa notare inoltre che l'endpoint va tenuto riservato, perché conoscerlo basta per inviare messaggi a quell'utente.

iPhone e iPad

WebKit ha introdotto il Web Push per le app web in iOS e iPadOS 16.4, con due condizioni dal suo annuncio: il sito deve essere aggiunto alla schermata Home, e il permesso deve essere richiesto in risposta a un'azione dell'utente, come un tocco su un pulsante Iscriviti. Quindi su iPhone le push raggiungono solo gli utenti che hanno installato la tua app web. Vedi app native vs progressive web app per capire cosa significhi installare un'app web.

Chiedere il permesso nel modo giusto

Non chiedere alla prima visita. Spiega prima il vantaggio ("Ricevi un promemoria un'ora prima della lezione"), poi mostra la richiesta del browser quando l'utente tocca un pulsante. Se qualcuno rifiuta, il browser potrebbe non permetterti di chiedere di nuovo, quindi una richiesta prematura può farti perdere quell'utente per sempre.

Le notifiche programmate richiedono un trigger

"Promemoria 24 ore prima" o "riepilogo settimanale ogni lunedì" hanno bisogno di qualcosa che giri a orari prestabiliti. È un problema di job in background, trattato in come eseguire i job in background. Uno schema comune: uno scheduler esterno chiama un endpoint protetto ogni pochi minuti, e quell'endpoint invia tutto ciò che è in scadenza.

Prompt da dare al tuo builder IA

Inizia dalle notifiche in-app:

Aggiungi notifiche in-app. Crea una tabella notifications (utente, tipo, titolo, testo, link, created_at, read_at). Aggiungi una funzione server notify(userId, type, data) che ogni funzionalità chiama. Mostra un'icona a campanella nell'intestazione con il conteggio dei non letti, un menu a tendina con le ultime 20, e un pulsante "Segna tutte come lette". Controlla le nuove notifiche ogni 60 secondi.

Poi preferenze ed email:

Aggiungi le impostazioni delle notifiche: per ogni tipo (risposte ai commenti, menzioni, fatturazione), l'utente sceglie in-app, email, entrambe o nessuna. notify() deve rispettare queste scelte. Invia le email tramite [PROVIDER] usando il segreto [ENV_NAME], solo sul server. Raggruppa le email dei commenti in modo che un utente riceva al massimo una email ogni 15 minuti.

Poi le push, se ti servono:

Aggiungi le push web opzionali. Registra un service worker, genera le chiavi VAPID e salva la chiave privata come segreto. Aggiungi un pulsante "Attiva notifiche" nelle impostazioni che chieda il permesso solo quando viene cliccato. Salva ogni sottoscrizione per utente e dispositivo, invia le push da notify() quando l'utente ha scelto di riceverle, ed elimina le sottoscrizioni che il servizio push segnala come scadute.

Errori comuni

• Notifiche sparse nel codice. Ogni funzionalità invia la propria email in modo diverso, e le preferenze vengono ignorate. Usa un'unica funzione notify().
• Chiedere il permesso per le push al caricamento della pagina. La maggior parte delle persone rifiuta, e potresti non avere un'altra occasione.
• Nessuna preferenza. Chi non può disattivare gli avvisi fastidiosi li disattiva tutti, oppure se ne va.
• Inviare dal browser. Le chiavi per email e push devono stare sul server.
• Non ripulire le sottoscrizioni push non più valide. Quelle scadute si accumulano e sprecano invii.
• Dettagli sensibili nel testo della notifica. Le schermate di blocco li mostrano. "Hai un nuovo messaggio" è più sicuro del messaggio stesso.
• Nessuna traccia di cosa è stato inviato. Quando un utente dice "non ho mai ricevuto l'email", i log con gli ID dei messaggi del fornitore ti aiutano a capire perché.

Checklist

• Una funzione notify() lato server usata ovunque
• Tabella delle notifiche con stato di lettura, e una campanella con il conteggio dei non letti
• Preferenze dei canali per tipo, rispettate da notify()
• Email inviate dal server con un dominio verificato; riepilogo o raggruppamento per gli eventi frequenti
• Permesso per le push chiesto solo dopo un'azione dell'utente, con una spiegazione
• Push testate su desktop e su iPhone con l'app aggiunta alla schermata Home
• Sottoscrizioni push scadute rimosse
• Nessun contenuto sensibile nelle anteprime di push o email
• I promemoria programmati hanno un trigger affidabile

Notifiche su Mythex

Mythex non include un servizio integrato di email o push per le app che crei, quindi porti tu il tuo fornitore di posta elettronica e generi le tue chiavi push, salvate come segreti del progetto. La parte in-app richiede solo il database del progetto, che Mythex aggiunge quando lo chiedi. Costruisci con prompt come quelli sopra, testa la campanella e le email in Anteprima, e testa le push sull'URL pubblicato, perché i service worker e le push richiedono un indirizzo HTTPS reale. La ricetta della documentazione Inviare email dalla tua app contiene un prompt di partenza. Mythex non documenta i job programmati, quindi pianifica i promemoria a orario con un trigger esterno, come descritto in come eseguire i job in background.

Domande