अपने ऐप में Notifications कैसे जोड़ें: In-App, Email और Push

वेब ऐप में notifications जोड़ने के लिए in-app notifications से शुरू करें: आपके database में एक notifications table और एक bell icon जो unread आइटम दिखाए। जब लोग दूर हों तब उन्हें जानना ज़रूरी हो, तो एक email provider के ज़रिए email जोड़ें, और web push तभी जोड़ें जब समय पर अलर्ट मायने रखते हों, क्योंकि उसके लिए service worker, user की अनुमति और iPhone पर ऐप का Home Screen पर सहेजा होना ज़रूरी है। आप जो भी channels इस्तेमाल करें, हर notification सर्वर पर एक ही जगह से बनाएँ और users को चुनने दें कि उन्हें क्या मिले।

यह गाइड channels की तुलना करती है, एक सरल architecture दिखाती है, और AI app builder के साथ इस्तेमाल किए जा सकने वाले prompts देती है।

मुख्य channels की तुलना

ज़्यादातर ऐप्स को in-app और email दोनों चाहिए। Push और SMS तब फ़ायदेमंद हैं जब समय सच में मायने रखता हो, जैसे booking की याद दिलाना या order तैयार होना।

Notification system कैसे जुड़ता है

इसे सरल और केंद्रीय रखें:

1. कुछ होता है। कोई comment पोस्ट होता है, payment fail होता है, booking कल है।
2. आपका सर्वर एक function call करता है, जैसे notify(user, type, data)।
3. वह function user की preferences जाँचता है और notifications table में एक row लिखता है (bell के लिए)।
4. फिर वह उन दूसरे channels पर भेजता है जो user ने उस प्रकार के लिए चालू किए हैं: आपके provider के ज़रिए email, Push API के ज़रिए push।
5. Frontend unread notifications दिखाता है और खोलने पर उन्हें read मार्क करता है।

एक ही entry point का मतलब है कि आप codebase में खोज किए बिना channel जोड़ सकते हैं, शब्द बदल सकते हैं, या preferences का सम्मान कर सकते हैं।

क्या सहेजें

Notifications table को आमतौर पर चाहिए: user ID, type (जैसे comment_reply), एक छोटा title और body, संबंधित पेज का link, बनाने का समय, और पढ़ने का समय। एक अलग preferences table सहेजती है कि हर user हर type के लिए कौन से channels चाहता है।

नई notifications दिखाना

• पेज देखने पर लोड करें और हर 30–60 सेकंड पर poll करें। सरल और भरोसेमंद।
• WebSockets या server-sent events से real-time अपडेट तुरंत लगते हैं पर चलने वाले हिस्से बढ़ाते हैं। जब तक तुरंत अपडेट ज़रूरी न हों, polling से शुरू करें।

Email notifications

Email के लिए एक sending provider और एक verified domain चाहिए; विवरण अपने ऐप से emails कैसे भेजें में हैं। Notifications के लिए खास बातें:

• सर्वर से भेजें, कभी browser में provider key रखकर नहीं।
• बार-बार होने वाली घटनाओं को batch करें। एक email में "3 new comments" तीन emails से बेहतर है।
• कम ज़रूरी गतिविधि के लिए daily या weekly digest दें।
• गैर-ज़रूरी email में unsubscribe या preferences link दें। Marketing email के नियम देश के हिसाब से अलग हैं; जाँचें कि आप पर क्या लागू होता है।

Web push notifications

Web push आपकी साइट को ऐसे अलर्ट भेजने देता है जो ऐप notifications की तरह दिखते हैं। MDN के Push API documentation के अनुसार यह ऐसे काम करता है:

1. आपकी साइट एक service worker रजिस्टर करती है, एक script जिसे browser पृष्ठभूमि में चला सकता है।
2. User सहमत होने के बाद, service worker PushManager.subscribe() के ज़रिए subscribe करता है। Browser एक subscription लौटाता है, जिसमें एक endpoint और encryption keys होती हैं।
3. आपका सर्वर वह subscription सहेजता है और जब कुछ होता है, तो endpoint पर संदेश भेजता है, आमतौर पर VAPID keys से signed (एक key pair जो आपके सर्वर की पहचान करता है)।
4. Browser आपका service worker शुरू करता है, जो notification दिखाता है, भले ही आपका पेज खुला न हो।

MDN यह भी बताता है कि endpoint गुप्त रखना चाहिए, क्योंकि उसे जानना ही उस user को संदेश भेजने के लिए काफ़ी है।

iPhone और iPad

WebKit ने iOS और iPadOS 16.4 में web apps के लिए Web Push जोड़ा, और उसकी घोषणा के अनुसार दो शर्तें हैं: साइट को Home Screen पर जोड़ा जाना चाहिए, और अनुमति किसी user action के जवाब में माँगी जानी चाहिए, जैसे Subscribe button पर tap। तो iPhone पर push केवल उन्हीं users तक पहुँचता है जिन्होंने आपका web app इंस्टॉल किया है। Web app इंस्टॉल करने का मतलब क्या है, इसके लिए native बनाम progressive web apps देखें।

अनुमति सही तरीके से माँगना

पहली बार आने पर न पूछें। पहले फ़ायदा समझाएँ ("अपनी क्लास से एक घंटा पहले reminder पाएँ"), फिर user के button tap करने पर browser का prompt दिखाएँ। अगर कोई मना कर दे, तो browser आपको दोबारा पूछने न दे, इसलिए समय से पहले का prompt उन्हें हमेशा के लिए खो सकता है।

Scheduled notifications के लिए एक trigger चाहिए

"24 घंटे पहले reminder" या "हर सोमवार साप्ताहिक सारांश" के लिए कुछ चाहिए जो शेड्यूल पर चले। यह background-job की समस्या है, जिसे background jobs कैसे चलाएँ में समझाया गया है। एक आम पैटर्न: एक बाहरी scheduler हर कुछ मिनट में एक protected endpoint को call करता है, और वह endpoint जो भी देय है, भेज देता है।

AI builder को दिए जाने वाले prompts

In-app से शुरू करें:

In-app notifications जोड़ो। एक notifications table बनाओ (user, type, title, body, link, created_at, read_at)। एक सर्वर function notify(userId, type, data) जोड़ो जिसे हर feature call करे। Header में unread count वाला bell icon दिखाओ, नवीनतम 20 का dropdown, और "सभी को read मार्क करें" button। हर 60 सेकंड पर नई notifications के लिए poll करो।

फिर preferences और email:

Notification settings जोड़ो: हर type (comment replies, mentions, billing) के लिए user in-app, email, दोनों या कोई नहीं चुने। notify() इन्हें माने। [PROVIDER] से email भेजो, सर्वर पर केवल secret [ENV_NAME] इस्तेमाल करके। Comment emails को group करो ताकि एक user को 15 मिनट में अधिकतम एक email मिले।

फिर push, अगर चाहिए:

वैकल्पिक web push जोड़ो। Service worker रजिस्टर करो, VAPID keys बनाओ और private key को secret के रूप में सहेजो। Settings में "Enable notifications" button जोड़ो जो केवल क्लिक होने पर अनुमति माँगे। हर subscription को user और device के हिसाब से सहेजो, notify() से push भेजो जब user ने opt in किया हो, और जिन subscriptions को push service expired बताए उन्हें हटाओ।

आम गलतियाँ

• Notifications कोड में बिखरी हुई। हर feature अपना email अलग तरीके से भेजता है, और preferences अनदेखी रह जाती हैं। एक notify() function इस्तेमाल करें।
• पेज लोड होते ही push की अनुमति माँगना। ज़्यादातर लोग मना कर देते हैं, और दोबारा मौका शायद न मिले।
• कोई preferences न होना। जो users शोर वाले अलर्ट बंद नहीं कर सकते, वे सब बंद कर देते हैं, या चले जाते हैं।
• Browser से भेजना। Email और push keys सर्वर पर रहनी चाहिए।
• मृत push subscriptions साफ़ न करना। Expired subscriptions जमा होती जाती हैं और भेजने का समय बर्बाद करती हैं।
• Notification text में संवेदनशील विवरण। Lock screens पर वह दिखता है। "आपको एक नया संदेश मिला है" संदेश की सामग्री से सुरक्षित है।
• क्या भेजा गया उसका कोई रिकॉर्ड न होना। जब user कहे "मुझे email नहीं मिला", तो provider message IDs वाले logs से पता लगाने में मदद मिलती है।

चेकलिस्ट

• एक server-side notify() function जो हर जगह इस्तेमाल होता है
• Read state वाली notifications table, और unread count वाला bell
• हर type के लिए channel preferences, जिन्हें notify() मानता है
• Verified domain के साथ सर्वर से भेजी गई email; बार-बार होने वाली घटनाओं के लिए digest या grouping
• Push की अनुमति केवल user action के बाद, स्पष्टीकरण के साथ
• Push desktop पर और उस iPhone पर टेस्ट किया गया जिस पर ऐप Home Screen पर जुड़ा है
• Expired push subscriptions हटाई जाती हैं
• Push या email के preview में कोई संवेदनशील सामग्री नहीं
• Scheduled reminders के लिए भरोसेमंद trigger है

Mythex में Notifications

Mythex आपके बनाए ऐप्स के लिए built-in email या push सेवा शामिल नहीं करता, इसलिए आप अपना email provider लाते हैं और अपनी push keys ख़ुद बनाते हैं, जो प्रोजेक्ट secrets में सहेजी जाती हैं। In-app वाला हिस्सा केवल प्रोजेक्ट के database की ज़रूरत रखता है, जिसे आपके माँगने पर Mythex जोड़ता है। ऊपर जैसे prompts से बनाएँ, Preview में bell और emails टेस्ट करें, और push अपने published URL पर टेस्ट करें, क्योंकि service workers और push को एक असली HTTPS पते की ज़रूरत होती है। Docs की recipe अपने ऐप से email भेजें में एक starter prompt है। Mythex scheduled jobs का दस्तावेज़ नहीं देता, इसलिए समय वाले reminders के लिए background jobs कैसे चलाएँ में बताए गए बाहरी trigger की योजना बनाएँ।

सवाल