إعدادات التخزين المؤقت لتقليل عدد استدعاءات Serverless لتطبيقات Nuxt التي تعمل على Vercel
2026년 5월 1일
0
Computing/SoftwareRelated Video
36:54▲ جلسة مجتمعية: Nuxt على Vercel
Vercel
Comments (0)
Log in to leave a comment
No posts yet
36:54Vercel
Log in to leave a comment
No posts yet
يبدو محرك Nitro الخاص بـ Nuxt وكأنه يعمل بشكل جيد في أي مكان، ولكن بمجرد رفعه على Vercel Edge Runtime، تختلف القصة تماماً. السبب في أن المكتبات مثل sharp أو bcrypt التي كانت تعمل بشكل مثالي محلياً تخرج خطأ 500 فور النشر هو أن Vercel Edge يمنع الوصول إلى وحدات Node.js القياسية. أنا شخصياً أقوم دائماً بتشغيل npx vercel build قبل الضغط على زر النشر. إذا لم تقم بمحاكاة البيئة القائمة على Linux مسبقاً، فمن المحتمل جداً أن تصارع أخطاء وقت التشغيل (Runtime Errors) في الساعة الثالثة صباحاً.
إذا كنت ترغب في تشغيل مستقر، فمن الأسلم تحديد الـ preset كـ vercel عادي بدلاً من vercel-edge في ملف nuxt.config.ts. ليس من الضروري تشغيل جميع واجهات البرمجة (APIs) على الـ Edge. كما يجب توحيد استدعاء متغيرات البيئة باستخدام useRuntimeConfig الخاصة بـ Nitro بدلاً من استدعاء process.env مباشرة. هذه العادة البسيطة تقضي على 80% من أخطاء وقت التشغيل التي تحدث بعد النشر.
المتسبب الرئيسي في فواتير Vercel هو وقت تشغيل وظائف Serverless وعدد استدعاءاتها. تُعد routeRules التي يوفرها Nitro 3 أقوى أداة لتقليل هذه التكاليف فعلياً. إذا استخدمت استراتيجية stale-while-revalidate (SWR) بشكل صحيح، فحتى لو جاء 10,000 طلب إلى واجهة البرمجة، سينتهي الأمر بتنفيذ الوظيفة الفعلية مرة واحدة فقط. إنها طريقة ذكية لمنح المستخدم استجابة سريعة في أجزاء من الثانية مع الحفاظ على محفظتك.
إليك الإعدادات المحددة لتقليل التكاليف بنسبة تزيد عن 40%:
routeRules داخل ملف nuxt.config.ts.swr: 3600 إلى ذلك المسار لتفعيل وضع التحديث في الخلفية لمدة ساعة واحدة.maxAge و staleMaxAge داخل خيار cache.بهذه الطريقة، ستلاحظ انخفاضاً حاداً في عدد استدعاءات وظائف Serverless على لوحة تحكم Vercel.
أخطاء الهيدريشن التي تحدث عندما يلتقي ملف HTML الذي أنشأه الخادم مع JavaScript الخاص بالعميل تجعل التطبيق غير مستقر. تم تصميم Nuxt 4 لحل هذه المشكلة باستخدام deep: false كقيمة افتراضية عند استدعاء useAsyncData. بدلاً من تتبع الكائنات غير الضرورية، يتم توفير الذاكرة ونقل حالة الخادم إلى العميل بأمان.
طبق القواعد الثلاث التالية لضبط عدم تطابق البيانات وتقليل حجم الحمولة (Payload):
pick عند استدعاء API لاختيار قيم المفاتيح الضرورية فقط لتقديم القالب. هذا وحده يقلل حجم الحمولة بنسبة تصل إلى 50%.useId() في الأماكن التي تتطلب معرفاً فريداً لمطابقة المعرفات بين الخادم والعميل.<NuxtTime> لمعالجتها بناءً على الإعدادات المحلية للمتصفح.مع نمو المشروع، قد لا تكفي ذاكرة حاوية بناء Vercel البالغة 8,192 ميجابايت. وبشكل أدق، يتم تعيين حجم الـ Heap الافتراضي لـ Node.js ليكون أصغر من الذاكرة المتاحة، مما يؤدي إلى تكرار عمليات Garbage Collection وتوقف البناء في النهاية.
لتسريع عملية البناء ومنع فشل النشر، طبق الإعدادات التالية فوراً:
NODE_OPTIONS="--max-old-space-size=4096" إلى متغيرات بيئة مشروع Vercel. مجرد رفع قيود ذاكرة الـ Heap سيؤدي إلى اختفاء عنق الزجاجة في عملية البناء.npx nuxt analyze للتأكد من أن التبعيات الثقيلة الخاصة بالخادم فقط غير مختلطة في حزمة العميل (Client Bundle)، وقم بعزلها باستخدام الاختصار #server.server/middleware/ الذي يعمل مع كل طلب إلى داخل معالجات الأحداث (Event Handlers) لمسارات محددة لتقليل حجم حزمة الخادم.بمجرد الانتهاء من تهيئة هذه البيئة، سيتم تقصير وقت انتظار خط أنابيب CI/CD وسينخفض معدل فشل النشر بشكل ملحوظ.