Written with AI assistance from the source video. The video is the authority.
30:37Vercel
Log in to leave a comment
No posts yet
Notion का इंटरफ़ेस उपयोग करने में आसान है। यही कारण है कि जब किसी अकेले डेवलपर के पास सर्वर और डेटाबेस अलग से सेट अप करने का समय नहीं होता है, तो वह Notion को बैकएंड के रूप में उपयोग करता है। हालांकि, यदि आप प्रोडक्शन लेवल पर इस संरचना को बनाए रखते हैं, तो आप जल्द ही समस्याओं में फंस जाएंगे। Notion API हर इंटीग्रेशन टोकन पर प्रति सेकंड 3 अनुरोधों (requests) की सीमा लगाता है। इस सीमा को पार करने पर 429 या 529 त्रुटियां (errors) आने लगती हैं।
थोड़ा सा भी डेटा जमा होते ही समस्या बड़ी हो जाती है। एक बार में अधिक से अधिक 100 डेटा ही लाए जा सकते हैं। पेजिंग प्रोसेसिंग को खुद ही लागू करना पड़ता है, और नेस्टेड प्रॉपर्टी संरचना को पार्स करने के कारण सर्वर का लॉजिक जटिल हो जाता है। एक पेज में आने वाले प्रॉपर्टी डेटा का आकार 2.5 मेगाबाइट तक सीमित होता है। यदि आप इस सीमा को नजरअंदाज करके सेवा को तैनात (deploy) करते हैं, तो उपयोगकर्ता के अनुरोध बढ़ने पर स्क्रीन फ्रीज हो जाती है या डेटा गायब हो जाता है।
आप हर बार बाहरी API कॉल का इंतजार नहीं कर सकते। इसके आगे एक Caching लेयर रखनी होगी। Redis या Cloudflare KV में स्टैटिक डेटा को कैश करना चाहिए, और बैकग्राउंड वर्कर के साथ समय-समय पर इसे अपडेट करना चाहिए ताकि कुल API कॉल का 80 प्रतिशत हिस्सा स्थानीय (local) रूप से प्रोसेस हो सके। रिस्पांस स्पीड 200 मिलीसेकंड से कम हो जाती है।
Python बैकएंड में Notion की जटिल प्रॉपर्टीज़ को फ़्लैट करने वाले एक पार्सर की भी आवश्यकता होती है। Notion का रिस्पांस टाइप के अनुसार गहराई से नेस्टेड होता है। एक ऐसा पार्सर बनाया जाना चाहिए जो डिक्शनरी को ट्रैवर्स करे, टाइप फ़ील्ड की जाँच करें, टेक्स्ट को स्ट्रिंग में जोड़े, और रिलेशनल डेटा से केवल ID सरणी (array) निकाले। इस प्री-प्रोसेसिंग प्रक्रिया से गुजरने के बाद ही फ्रंटएंड डेवलपर बिना पार्सिंग लॉजिक के सीधे डेटा का उपयोग कर सकता है।
Notion में कोई पंक्ति (row) बदलने पर भी, यदि Webhook प्राप्त होते ही API को कॉल किया जाए, तो पुराना डेटा वापस आ जाता है। ऐसा इसलिए होता है क्योंकि इंडेक्सिंग में देरी (delay) होती है। यही पैकेट के नुकसान या डेटा के उलझने का कारण है।
इस समस्या को हल करने के लिए एक आवधिक (periodic) बैकग्राउंड रिकवरी रूटीन की आवश्यकता होती है। Notion API के मॉडिफिकेशन टाइम फ़िल्टर का उपयोग करके लोकल कैशे और टाइमस्टैम्प की तुलना करें। यदि कोई त्रुटि होती है, तो एक्सपोनेंशियल बैकऑफ़ एल्गोरिथ्म के साथ प्रतीक्षा करें और फिर से प्रयास करें। डेटा अखंडता (integrity) को बनाए रखने के लिए अंतिम सिंक्रोनीकरण समय के बाद बदले गए केवल रिकॉर्ड को चुनकर जबरन अपडेट करने का एक रूटीन एम्बेड करना होगा।
क्लाइंट ब्राउज़र में सीधे Notion सीक्रेट कुंजी रखकर अनुरोध भेजने वाला कोड खतरनाक है। टोकन वैसे ही उजागर हो जाते हैं और CORS की समस्या भी उत्पन्न होती है। यही कारण है कि बीच में एक सर्वरलेस मिडलवेयर प्रॉक्सी होना चाहिए।
क्लाइंट सर्वरलेस मिडलवेयर को अनुरोध भेजता है, और मिडलवेयर सर्वर पर्यावरण चर (environment variables) में छिपे टोकन को जोड़कर Notion API के साथ संचार करता है। यदि यह एक मल्टी-टेनेंट वातावरण है, तो मिडलवेयर में एक रिवर्स-ऑथराइजेशन टेबल होनी चाहिए जो ऐप उपयोगकर्ता ID और Notion पेज के मालिक को मैप करे। इस संरचना को बनाने से ही टोकन लीक होने की दुर्घटनाओं को रोका जा सकता है और डेटा को सुरक्षित रूप से अलग (isolate) किया जा सकता है।