Cum adaugi notificări în aplicația ta: în aplicație, email și push

Pentru a adăuga notificări la o aplicație web, începe cu notificările din aplicație: un tabel de notificări în baza de date și o iconiță de clopoțel care arată elementele necitite. Adaugă email pentru lucruri pe care oamenii trebuie să le știe când nu sunt în aplicație, folosind un furnizor de email, iar web push doar când alertele la timp contează, pentru că necesită un service worker, permisiunea utilizatorului și, pe iPhone, aplicația salvată pe ecranul principal. Indiferent de canalele folosite, creează fiecare notificare într-un singur loc, pe server, și lasă utilizatorii să aleagă ce primesc.

Acest ghid compară canalele, arată o arhitectură simplă și oferă prompturi pe care le poți folosi cu un constructor de aplicații cu AI.

Canalele principale comparate

Majoritatea aplicațiilor au nevoie de înăuntru plus email. Push și SMS merită când timpul contează cu adevărat, precum un memento de rezervare sau o comandă gata de ridicat.

Cum se potrivesc împreună părțile unui sistem de notificări

Ține-l simplu și centralizat:

1. Se întâmplă ceva. Se postează un comentariu, o plată eșuează, o rezervare este mâine.
2. Serverul tău apelează o singură funcție, de exemplu notify(user, type, data).
3. Funcția verifică preferințele utilizatorului și scrie un rând în tabelul notifications (pentru clopoțel).
4. Apoi trimite către celelalte canale pe care utilizatorul le-a activat pentru tipul respectiv: emailul prin furnizorul tău, push-ul prin Push API.
5. Frontendul arată notificările necitite și le marchează ca citite când sunt deschise.

Un singur punct de intrare înseamnă că poți adăuga un canal, schimba formularea sau respecta preferințele fără să cauți prin toată baza de cod.

Ce să stochezi

Un tabel de notificări are de obicei nevoie de: ID-ul utilizatorului, tipul (de exemplu comment_reply), un titlu și un text scurt, un link către pagina relevantă, ora creării și ora citirii. Un tabel separat de preferințe stochează ce canale vrea fiecare utilizator pentru fiecare tip.

Afișarea notificărilor noi

• Încarcă la vizualizarea paginii și fă polling la fiecare 30–60 de secunde. Simplu și fiabil.
• Actualizări în timp real cu WebSockets sau server-sent events par instantanee, dar adaugă piese în mișcare. Începe cu polling, dacă actualizările instantanee nu contează cu adevărat.

Notificări prin email

Emailul are nevoie de un furnizor de trimitere și de un domeniu verificat; detaliile sunt în cum trimiți emailuri din aplicația ta. Pentru notificări în mod specific:

• Trimite de pe server, niciodată cu o cheie a furnizorului în browser.
• Grupează evenimentele care vin des. „3 comentarii noi” într-un singur email bate trei emailuri.
• Oferă un rezumat zilnic sau săptămânal pentru activitatea cu prioritate mică.
• Include un link de dezabonare sau de preferințe în emailurile care nu sunt esențiale. Regulile pentru emailul de marketing diferă de la țară la țară; verifică ce se aplică în cazul tău.

Notificări web push

Web push permite site-ului tău să trimită alerte care apar ca notificările unei aplicații. Conform documentației Push API de pe MDN, funcționează astfel:

1. Site-ul tău înregistrează un service worker, un script pe care browserul îl poate rula în fundal.
2. După ce utilizatorul este de acord, service worker-ul se abonează prin PushManager.subscribe(). Browserul returnează un abonament cu un endpoint și chei de criptare.
3. Serverul tău stochează acel abonament și, când se întâmplă ceva, trimite un mesaj către endpoint, de obicei semnat cu chei VAPID (o pereche de chei care îți identifică serverul).
4. Browserul pornește service worker-ul tău, care afișează notificarea, chiar dacă pagina ta nu este deschisă.

MDN notează și că endpoint-ul trebuie păstrat secret, pentru că cunoașterea lui este suficientă ca să trimiți mesaje către acel utilizator.

iPhone și iPad

WebKit a adăugat Web Push pentru aplicațiile web în iOS și iPadOS 16.4, cu două condiții din anunțul lor: site-ul trebuie adăugat pe ecranul principal, iar permisiunea trebuie cerută ca răspuns la o acțiune a utilizatorului, precum un tap pe un buton de abonare. Deci pe iPhone, push-ul ajunge doar la utilizatorii care și-au instalat aplicația web. Vezi aplicații native vs aplicații web progresive ca să înțelegi ce înseamnă instalarea unei aplicații web.

Cum ceri permisiunea corect

Nu cere la prima vizită. Explică mai întâi beneficiul („Primești un memento cu o oră înainte de curs”), apoi arată promptul browserului când utilizatorul apasă un buton. Dacă cineva refuză, browserul poate să nu te lase să ceri din nou, deci un prompt prematur poate să îl pierzi definitiv.

Notificările programate au nevoie de un declanșator

Mementourile „cu 24 de ore înainte” sau „rezumatul săptămânal în fiecare luni” au nevoie de ceva care rulează după un program. Aceasta este o problemă de joburi în fundal, acoperită în cum rulezi joburi în fundal. Un model comun: un planificator extern apelează la fiecare câteva minute un endpoint protejat, iar acel endpoint trimite ce este scadent.

Prompturi pentru constructorul tău cu AI

Începe cu notificările din aplicație:

Adaugă notificări în aplicație. Creează un tabel notifications (user, type, title, body, link, created_at, read_at). Adaugă o funcție de server notify(userId, type, data) pe care o apelează fiecare funcționalitate. Arată o iconiță de clopoțel în antet cu un număr de necitite, un dropdown cu ultimele 20 și un buton „marchează toate ca citite”. Fă polling pentru notificări noi la fiecare 60 de secunde.

Apoi preferințele și emailul:

Adaugă setări de notificări: pentru fiecare tip (răspunsuri la comentarii, mențiuni, facturare), lasă utilizatorul să aleagă în aplicație, email, ambele sau niciunul. notify() trebuie să respecte aceste setări. Trimite emailul prin [PROVIDER] folosind secretul [ENV_NAME], doar pe server. Grupează emailurile despre comentarii, astfel încât un utilizator să primească cel mult un email la 15 minute.

Apoi push, dacă ai nevoie:

Adaugă web push opțional. Înregistrează un service worker, generează chei VAPID și stochează cheia privată ca secret. Adaugă un buton „Activează notificările” în setări care cere permisiunea doar când este apăsat. Stochează fiecare abonament pe utilizator și dispozitiv, trimite push-uri din notify() când utilizatorul s-a abonat și șterge abonamentele pe care push-ul le raportează ca expirate.

Greșeli frecvente

• Notificări împrăștiate prin cod. Fiecare funcționalitate trimite propriul email în felul ei, iar preferințele sunt ignorate. Folosește o singură funcție notify().
• Cererea permisiunii push la încărcarea paginii. Majoritatea oamenilor refuză, iar s-ar putea să nu mai ai o altă șansă.
• Fără preferințe. Utilizatorii care nu pot opri alertele deranjante le opresc pe toate sau pleacă.
• Trimiterea din browser. Cheile pentru email și push trebuie să stea pe server.
• Abonamentele push moarte nu sunt curățate. Abonamentele expirate se adună și irosesc trimiterile.
• Detalii sensibile în textul notificării. Ecranele de blocare le afișează. „Ai un mesaj nou” este mai sigur decât mesajul în sine.
• Fără evidența a ceea ce s-a trimis. Când un utilizator spune „nu am primit emailul”, jurnalele cu ID-urile mesajelor de la furnizor te ajută să afli de ce.

Lista de verificare

• O singură funcție notify() pe server, folosită peste tot
• Tabel de notificări cu starea de citire și un clopoțel cu număr de necitite
• Preferințe de canal pe tip, respectate de notify()
• Email trimis de pe server cu domeniu verificat; grupare sau rezumat pentru evenimentele care vin des
• Permisiunea push cerută doar după o acțiune a utilizatorului, cu o explicație
• Push testat pe desktop și pe un iPhone cu aplicația adăugată pe ecranul principal
• Abonamentele push expirate eliminate
• Niciun conținut sensibil în previzualizările push sau email
• Mementourile programate au un declanșator sigur

Notificări pe Mythex

Mythex nu include un serviciu încorporat de email sau push pentru aplicațiile pe care le construiești, așa că aduci propriul furnizor de email și îți generezi propriile chei push, stocate ca secrete ale proiectului. Partea din aplicație are nevoie doar de baza de date a proiectului, pe care Mythex o adaugă când o ceri. Construiește cu prompturi ca cele de mai sus, testează clopoțelul și emailurile în Preview și testează push-ul pe URL-ul publicat, pentru că service worker-ele și push-ul au nevoie de o adresă HTTPS reală. Rețeta din documentație Trimite email din aplicația ta are un prompt de pornire. Mythex nu documentează joburi programate, deci planifică memento-urile cu timp printr-un declanșator extern, așa cum este descris în cum rulezi joburi în fundal.

Întrebări