makedream
36:54Vercel
Log in to leave a comment
No posts yet
Nuxt का Nitro इंजन हर जगह अच्छी तरह से काम करता हुआ प्रतीत होता है, लेकिन जैसे ही इसे Vercel Edge Runtime पर रखा जाता है, स्थिति बदल जाती है। sharp या bcrypt जैसी लाइब्रेरी, जो लोकल पर ठीक काम करती थीं, डिप्लॉयमेंट के तुरंत बाद 500 एरर देने लगती हैं क्योंकि Vercel Edge, Node.js स्टैंडर्ड मॉड्यूल एक्सेस को ब्लॉक कर देता है। मैं डिप्लॉय बटन दबाने से पहले हमेशा npx vercel build चलाता हूँ। यदि आप पहले से Linux-आधारित परिवेश का अनुकरण नहीं करते हैं, तो सुबह 3 बजे रनटाइम एरर से जूझने की संभावना बहुत अधिक होती है।
यदि आप स्थिर संचालन चाहते हैं, तो nuxt.config.ts में प्रीसेट को vercel-edge के बजाय सामान्य vercel के रूप में स्पष्ट रूप से निर्दिष्ट करना सुरक्षित है। सभी API को Edge पर चलाने की आवश्यकता नहीं है। एनवायरनमेंट वेरिएबल्स के लिए भी process.env को सीधे कॉल न करें, बल्कि Nitro के useRuntimeConfig का उपयोग करके इसे मानकीकृत करें। यह छोटी सी आदत डिप्लॉयमेंट के बाद होने वाली 80% रनटाइम एरर को खत्म कर देती है।
Vercel बिलिंग का मुख्य कारण सर्वरलेस फंक्शन्स का निष्पादन समय (execution time) और कॉल की संख्या है। Nitro 3 में उपलब्ध routeRules इस लागत को भौतिक रूप से कम करने का सबसे शक्तिशाली उपकरण है। यदि आप stale-while-revalidate (SWR) रणनीति का सही ढंग से उपयोग करते हैं, तो भले ही 10,000 API अनुरोध आएं, वास्तविक फ़ंक्शन केवल एक बार ही निष्पादित होगा। यह उपयोगकर्ताओं को मिलीसेकंड में तेज़ प्रतिक्रिया देने और साथ ही आपके वॉलेट को सुरक्षित रखने का एक स्मार्ट तरीका है।
लागत को 40% से अधिक कम करने के लिए विशिष्ट कॉन्फ़िगरेशन यहाँ दिया गया है:
nuxt.config.ts के routeRules ऑब्जेक्ट में उन पाथ (paths) को निर्दिष्ट करें जिन्हें आप कैश करना चाहते हैं।swr: 3600 जोड़ें ताकि 1 घंटे के लिए बैकग्राउंड रिफ्रेश मोड सक्षम हो सके।cache विकल्प के भीतर maxAge और staleMaxAge को स्पष्ट करें ताकि यह परिभाषित हो सके कि CDN कितनी देर तक कैश रखेगा।ऐसा करने पर, आप Vercel डैशबोर्ड में सर्वरलेस फ़ंक्शन कॉल की संख्या को तेजी से गिरते हुए देखेंगे।
जब सर्वर द्वारा बनाया गया HTML और क्लाइंट का जावास्क्रिप्ट मिलते हैं, तो उत्पन्न होने वाली हाइड्रेशन त्रुटियाँ ऐप को अस्थिर बना देती हैं। Nuxt 4 को इसे हल करने के लिए useAsyncData कॉल करते समय डिफ़ॉल्ट रूप से deep: false का उपयोग करने के लिए डिज़ाइन किया गया है। अनावश्यक ऑब्जेक्ट ट्रैकिंग को छोड़ने के बदले, यह मेमोरी बचाता है और सर्वर स्टेट को क्लाइंट तक सुरक्षित रूप से पहुँचाता है।
डेटा विसंगति को रोकने और पेलोड आकार कम करने के लिए इन तीन नियमों को लागू करें:
pick विकल्प का उपयोग करें ताकि केवल वही की-वैल्यू (key values) चुनें जो टेम्पलेट रेंडरिंग के लिए आवश्यक हैं। केवल इसी से पेलोड का आकार 50% तक कम हो सकता है।useId() का उपयोग करें।<NuxtTime> कंपोनेंट के साथ रैप करें ताकि वे ब्राउज़र लोकेल के आधार पर प्रोसेस हों।जैसे-जैसे प्रोजेक्ट बढ़ता है, Vercel बिल्ड कंटेनर द्वारा प्रदान की गई 8,192MB मेमोरी भी कभी-कभी कम पड़ जाती है। सटीक रूप से कहें तो, Node.js का डिफ़ॉल्ट हीप साइज (heap size) उपलब्ध मेमोरी से छोटा सेट होता है, जिससे गार्बेज कलेक्शन बार-बार होता है और अंततः बिल्ड रुक जाता है।
बिल्ड स्पीड बढ़ाने और डिप्लॉयमेंट विफलता को रोकने के लिए, इन सेटिंग्स को तुरंत लागू करें:
NODE_OPTIONS="--max-old-space-size=4096" जोड़ें। हीप मेमोरी की सीमा हटाने मात्र से बिल्ड की बाधाएं दूर हो जाती हैं।npx nuxt analyze चलाएं और उन्हें #server एलियास (alias) के साथ अलग करें।server/middleware/ में मौजूद भारी लॉजिक, जो हर अनुरोध पर चलता है, उसे विशिष्ट पाथ के इवेंट हैंडलर के अंदर ले जाकर सर्वर बंडल का आकार कम करें।इस एनवायरनमेंट कॉन्फ़िगरेशन को पूरा करने के बाद, CI/CD पाइपलाइन का प्रतीक्षा समय कम हो जाएगा और डिप्लॉयमेंट विफलता की दर में काफी कमी आएगी।