أطلقت Cloudflare الإصدار 1.0 من Vinext، وهو إطار مفتوح المصدر يتيح تشغيل تطبيقات Next.js فوق Vite، مع إمكانية نشرها على منصات مثل Cloudflare Workers وNetlify وAWS Lambda. ويستهدف المشروع التطبيقات الجديدة والمشروعات القائمة، بما فيها تلك التي تستخدم Pages Router أو App Router، بدلاً من حصر الدعم في بنية Next.js الأحدث.
توافق أوسع مع تطبيقات Next.js
انتقل Vinext من تجربة مدفوعة بالذكاء الاصطناعي استمرت أسبوعاً عند إطلاقه في فبراير إلى إطار تقول Cloudflare إنه يُستخدم في الإنتاج مع تطبيقات عالية الحركة وديناميكية. وتذكر الشركة أن توافقه مع معظم الميزات التي طلبها العملاء يتجاوز 99%، مع استمرار اختبار السلوك الفعلي للتطبيقات لا مجرد محاكاة واجهات برمجية تحمل الأسماء نفسها.
يدعم الإصدار مساري App Router وPages Router، إضافة إلى التطبيقات الهجينة، ومكونات React على الخادم، وإجراءات الخادم، ومسارات API، ومعالجات المسارات، والبرمجيات الوسيطة، والتنقل من جهة العميل. كما يغطي طرق عرض الصفحات على الخادم، وإعادة البناء التدريجية للصفحات (ISR)، والتصدير إلى أصول ثابتة، وإعادة التحقق في الخلفية أو عند الطلب.
ما الذي يتغير عملياً؟
يوحد Vinext وظائف التخزين المؤقت بين المسارين وبيئات التشغيل المدعومة، مع دعم إضافي لـ Workers Cache. كما يوفر تتبعاً متوافقاً مع Next.js، ما يسمح باستمرار إعدادات OpenTelemetry وSentry الحالية، ويتكامل على Cloudflare Workers مع أدوات المراقبة الأصلية لـ Workers.
ويضيف الإصدار دعماً مباشراً لبيئة workerd أثناء التطوير والإنتاج، مع الوصول إلى روابط Cloudflare مثل تحسين الصور وHyperdrive. في المقابل، يظل دعم توجيه use cache المرتبط بـ Cache Components محدوداً؛ وتوضح Cloudflare أن الأولوية الحالية هي وظائف الإطار الأساسية التي تعتمد عليها التطبيقات في الإنتاج.
تسخين الذاكرة المؤقتة قبل الإطلاق
يقدم Vinext 1.0 آلية لتصيير الصفحات مسبقاً لمساري App Router وPages Router أثناء عملية البناء، ثم تقديمها عبر ISR وإبطالها بحسب المسار أو الوسم. لكنه يضيف خياراً مختلفاً لتطبيقات تحتوي على عشرات أو مئات الآلاف من عناوين URL: نقل جزء من التصيير المسبق من جهاز البناء إلى شبكة Cloudflare.
تستخدم ميزة cache warming مؤشرات Next.js المعتادة لتحديد الصفحات المطلوب تجهيزها، ويمكنها كذلك تحديد الصفحات ذات الحركة المرتفعة. وقبل تحويل الإصدار الجديد إلى حركة الإنتاج، تنشر Cloudflare نسخة Worker عند نسبة صفر بالمئة من الحركة، ثم تطلب الصفحات من تلك النسخة لملء الذاكرة المؤقتة، وبعد اكتمال العملية يمكن ترقية النشر. هذا يقلل انتظار البناء المتسلسل للصفحات قليلة الزيارات، لكنه يرتبط عملياً بالنشر على Cloudflare عند استخدام هذه الميزة.
الاختبارات ومسار الترحيل
تقول Cloudflare إن المشروع يعتمد آلاف الاختبارات التي تغطي سلوك الإطار، والخوادم في وضعي التطوير والإنتاج، وأهداف النشر على Node.js وCloudflare Workers. كما تُشغّل مجموعة اختبارات Next.js الشاملة على Vinext كل ليلة لرصد التراجعات الناتجة عن تغييرات المنبع. وتشمل عملية الترحيل أمرين للتحقق من توافق المشروع وإعداد Vite وتهيئة النشر مع الإبقاء على بنية مشروع Next.js السابقة: npx vinext check ثم npx vinext init.
يتوفر Vinext للمشروعات الجديدة والقائمة، ويمكن نشره على Cloudflare Workers مع تسخين الذاكرة المؤقتة باستخدام الأمر npx @vinext/cloudflare deploy --warm-cache. وتبقى مصفوفة التوافق، ودعم الميزات غير المكتمل مثل Cache Components، نقاطاً ينبغي على الفرق مراجعتها قبل اعتماد الترحيل في التطبيقات المعقدة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.