Paano Magdagdag ng Notification sa Iyong App: In-App, Email at Push

Para magdagdag ng notification sa web app, magsimula sa in-app notifications: isang notifications table sa database mo at bell icon na nagpapakita ng mga hindi pa nababasa. Idagdag ang email para sa mga bagay na kailangang malaman ng mga tao kapag wala sila, gamit ang email provider, at idagdag ang web push kapag talagang mahalaga ang mga napapanahong alerto, dahil nangangailangan ito ng service worker, pahintulot ng user at, sa iPhone, na naka-save ang app sa Home Screen. Anuman ang channel na gamitin mo, gumawa ng bawat notification sa iisang lugar sa server at hayaang pumili ang mga user kung ano ang gusto nilang matanggap.

Ikinukumpara ng gabay na ito ang mga channel, nagpapakita ng simpleng arkitektura, at nagbibigay ng mga prompt na magagamit mo sa AI app builder.

Ang mga pangunahing channel na pinaghahambing

Karamihan ng app ay nangangailangan ng in-app at email. Sulit ang push at SMS kapag talagang mahalaga ang oras, gaya ng paalala sa booking o order na handa na.

Paano nagkakasama ang isang sistema ng notification

Panatilihin itong simple at sentral:

1. May nangyari. May nag-comment, pumalya ang payment, o may booking bukas.
2. Tinatawag ng server mo ang isang function, gaya ng notify(user, type, data).
3. Tinitingnan ng function ang preferences ng user at nagsusulat ng row sa notifications table (para sa bell).
4. Pagkatapos ay nagpapadala sa iba pang channel na naka-on para sa uring iyon: email sa pamamagitan ng provider mo, push sa pamamagitan ng Push API.
5. Ipinapakita ng frontend ang mga hindi pa nababasang notification at minamarkahan ang mga ito bilang nabasa kapag binuksan.

Sa iisang entry point, madadagdagan mo ng channel, mababago ang wording, at masusunod ang preferences nang hindi naghahanap sa buong codebase.

Ano ang dapat i-store

Karaniwang kailangan ng notifications table ang: user ID, uri (halimbawa comment_reply), maikling pamagat at katawan, link sa kaugnay na page, oras ng paggawa, at oras ng pagbasa. Hiwalay na preferences table ang nag-iimbak kung aling channel ang gusto ng bawat user para sa bawat uri.

Pagpapakita ng mga bagong notification

• I-load kapag binuksan ang page at mag-poll kada 30–60 segundo. Simple at maaasahan.
• Real-time na update gamit ang WebSockets o server-sent events ay parang instant, pero may dagdag na mga gumagalaw na bahagi. Mag-polling muna maliban kung talagang mahalaga ang instant na update.

Mga email notification

Kailangan ng email ng sending provider at na-verify na domain; nasa paano magpadala ng email mula sa app mo ang mga detalye. Para sa mga notification partikular:

• Magpadala mula sa server, hindi kailanman gamit ang provider key sa browser.
• Pagsamahin ang madalas na event. Mas maganda ang "3 bagong comment" sa iisang email kaysa tatlong magkakahiwalay na email.
• Mag-alok ng araw-araw o lingguhang digest para sa aktibidad na mababa ang prayoridad.
• Maglagay ng unsubscribe o preferences link sa mga email na hindi mahalaga. Magkakaiba ang mga patakaran sa marketing email ayon sa bansa; tingnan kung ano ang naaangkop sa iyo.

Web push notifications

Hinahayaan ng web push ang site mo na magpadala ng mga alertong lumilitaw na parang notification ng app. Ayon sa dokumentasyon ng Push API sa MDN, ganito ito gumagana:

1. Nagre-register ang site mo ng service worker, isang script na kayang tumakbo ng browser sa background.
2. Pagkatapos sumang-ayon ng user, nag-s-subscribe ang service worker sa pamamagitan ng PushManager.subscribe(). Nagbabalik ang browser ng subscription na may endpoint at encryption keys.
3. Sini-store ng server mo ang subscription na iyon at, kapag may nangyari, nagpapadala ng mensahe sa endpoint, karaniwang nilalagdaan gamit ang VAPID keys (isang key pair na nagkikilala sa server mo).
4. Sinisimulan ng browser ang service worker mo, na nagpapakita ng notification kahit hindi bukas ang page mo.

Sinasabi rin ng MDN na dapat itago ang endpoint, dahil sapat nang malaman ito para makapagpadala ng mensahe sa user na iyon.

iPhone at iPad

Idinagdag ng WebKit ang Web Push para sa mga web app sa iOS at iPadOS 16.4, na may dalawang kondisyon ayon sa anunsyo nila: dapat naidagdag sa Home Screen ang site, at dapat hilingin ang pahintulot bilang tugon sa aksyon ng user gaya ng pag-tap sa Subscribe button. Kaya sa iPhone, ang push ay umaabot lang sa mga user na nag-install ng web app mo. Tingnan ang native vs progressive web apps para malaman kung ano ang ibig sabihin ng pag-install ng web app.

Maayos na paghingi ng pahintulot

Huwag humingi sa unang pagbisita. Ipaliwanag muna ang pakinabang ("Makakuha ng paalala isang oras bago ang klase mo"), tapos ipakita ang prompt ng browser kapag nag-tap ang user ng button. Kapag tumanggi ang isang tao, maaaring hindi na payagan ng browser na magtanong ulit, kaya ang maagang prompt ay maaaring tuluyang makawala sa kanila.

Ang mga naka-schedule na notification ay nangangailangan ng trigger

Ang "paalala 24 oras bago" o "lingguhang buod tuwing Lunes" ay nangangailangan ng bagay na tatakbo ayon sa schedule. Problema iyon ng background job, na sakop sa paano magpatakbo ng background jobs. Karaniwang pattern: tinatawag ng external scheduler ang isang protected endpoint bawat ilang minuto, at ipinapadala ng endpoint na iyon ang anumang dapat ipadala.

Mga prompt na ibibigay sa AI builder mo

Magsimula sa in-app:

Magdagdag ng in-app notifications. Gumawa ng notifications table (user, type, title, body, link, created_at, read_at). Magdagdag ng server function na notify(userId, type, data) na tinatawag ng bawat feature. Magpakita ng bell icon sa header na may bilang ng hindi pa nababasa, dropdown ng pinakabagong 20, at button na "mark all as read". Mag-poll para sa mga bago kada 60 segundo.

Pagkatapos, preferences at email:

Magdagdag ng notification settings: para sa bawat uri (comment replies, mentions, billing), hayaang pumili ang user ng in-app, email, pareho, o wala. Dapat sundin ng notify() ang mga ito. Magpadala ng email sa pamamagitan ng [PROVIDER] gamit ang secret na [ENV_NAME] sa server lamang. Pagsamahin ang comment emails para hindi makatanggap ang isang user ng higit sa isang email kada 15 minuto.

Pagkatapos, push, kung kailangan mo:

Magdagdag ng opsyonal na web push. Mag-register ng service worker, gumawa ng VAPID keys at itago ang private key bilang secret. Magdagdag ng "Enable notifications" button sa settings na humihingi ng pahintulot lamang kapag na-click. I-store ang bawat subscription kada user at device, magpadala ng push mula sa notify() kapag nag-opt in ang user, at burahin ang mga subscription na sinasabi ng push service na expired na.

Mga karaniwang pagkakamali

• Nakakalat na notification sa buong code. Bawat feature ay nagpapadala ng sariling email sa sariling paraan, at nababalewala ang preferences. Gumamit ng iisang notify() function.
• Paghingi ng push permission sa pag-load ng page. Karamihan ay tumatanggi, at baka wala nang pagkakataong magtanong ulit.
• Walang preferences. Ang mga user na hindi mapatay ang maiingay na alerto ay pinapatay na lang lahat, o umaalis.
• Pagpapadala mula sa browser. Sa server dapat ang email at push keys.
• Hindi paglilinis ng mga patay na push subscription. Nagtatambak ang mga expired na subscription at nasasayang ang mga pagpapadala.
• Sensitibong detalye sa teksto ng notification. Nakikita ito sa lock screen. Mas ligtas ang "May bago kang mensahe" kaysa sa mismong mensahe.
• Walang talaan ng ipinadala. Kapag sinabi ng user na "hindi ko natanggap ang email", makakatulong ang mga log na may message ID ng provider para malaman kung bakit.

Checklist

• Iisang server-side na notify() function na ginagamit saanman
• Notifications table na may read state, at bell na may bilang ng hindi pa nababasa
• Preferences ng channel kada uri, na sinusunod ng notify()
• Email na ipinapadala mula sa server na may na-verify na domain; digest o pagsasama-sama para sa madalas na event
• Push permission na hinihingi lamang pagkatapos ng aksyon ng user, may paliwanag
• Nasubukan ang push sa desktop at sa iPhone na naka-install ang app sa Home Screen
• Naaalis ang mga expired na push subscription
• Walang sensitibong nilalaman sa preview ng push o email
• May maaasahang trigger ang mga naka-schedule na paalala

Mga notification sa Mythex

Hindi kasama sa Mythex ang built-in na email o push service para sa mga app na ginagawa mo, kaya dadalhin mo ang sarili mong email provider at gagawa ng sarili mong push keys, na naka-store bilang project secrets. Ang in-app na bahagi ay nangangailangan lang ng database ng project, na idinadagdag ng Mythex kapag hiniling mo. Gumawa gamit ang mga prompt sa itaas, subukan ang bell at mga email sa Preview, at subukan ang push sa na-publish mong URL, dahil kailangan ng service worker at push ng totoong HTTPS address. Mayroong starter prompt ang docs recipe na Magpadala ng email mula sa app mo. Hindi pa dokumentado ng Mythex ang mga naka-schedule na job, kaya magplano ng mga timed na paalala gamit ang external trigger gaya ng nakasaad sa paano magpatakbo ng background jobs.

Mga tanong