المواقع الثابتة تبقى متاحة أثناء إعادة نشرها

كانت إعادة نشر موقع ثابت على Mythex تحذف الملفات الحية أولاً ثم ترفع البناء الجديد، فكان بعض الزوّار يحصلون خلال مدة الرفع على صفحة 404 أو على صفحة تفتقد سكربتاتها. وكان الرفع الفاشل قد يترك الموقع فارغاً أو نصف جديد. الآن يُكتب البناء الجديد فوق القديم، والصفحات آخر شيء، وتُزال البقايا بعد بضع دقائق. وإصلاح ثانٍ يجعل إعادة النشر تظهر خلال ثوانٍ بدل دقيقة، أو، لملفات مثل الشعار، خلال يوم كامل.

كيف يُقدَّم الموقع الثابت

الموقع الثابت هو موقع مكوّن من ملفات فقط: صفحات HTML، وJavaScript، وCSS، وصور. عندما تنشر واحداً على Mythex، نبنيه ونرفع ناتجه إلى تخزين الكائنات تحت مجلد خاص بموقعك، ونقدّمه عبر شبكة حافة، أي خوادم قريبة من زوّارك تجلب الملفات من التخزين وتحتفظ بنسخ منها لفترة. (إن كنت جديداً على الفكرة، فدليلنا عن ما هي شبكة CDN يشرحها.)

كان هناك خللان: ترتيب تغيير الملفات أثناء إعادة النشر، والمدة التي تبقى فيها النسخ القديمة محفوظة.

المشكلة الأولى: الرفع كان يفرّغ الموقع أولاً

كانت إعادة النشر تحذف كل شيء في مجلد الموقع، ثم ترفع البناء الجديد. طوال مدة الرفع، وكانت 12 ثانية لموقع من 250 ملفاً في اختبارنا المحلي، كان الزائر الذي لم يُخزَّن طلبه مسبقاً في الحافة يحصل على 404، أو على صفحة HTML تعيد سكربتاتها 404.

وكان الرفع الفاشل أسوأ. كان المجلد فارغاً بالفعل، وعلى أحد مساري الرفع كان يمكن أن يُكتب index.html الجديد قبل الملف الذي فشل. وقد يبقى موقع نصف جديد مباشراً بعد إعلان فشل النشر.

الإصلاح: الكتابة فوق القديم، والصفحات أخيراً، والحذف لاحقاً

1. لا تحذف أولاً. يُرفع البناء الجديد فوق القديم.
2. الأصول قبل الصفحات. الصفحة تسمّي السكربتات والأنماط التي تحتاجها، لذلك ترفع الصفحات في النهاية. وحتى تصل الصفحات الجديدة، يحصل الزوّار على الصفحة القديمة، التي تسمّي الأصول القديمة، وهي ما زالت موجودة. وعندما تصل، تكون الأصول الجديدة التي تسمّيها موجودة فعلاً.
3. أزل البقايا لاحقاً. قبل الرفع، نسرد ما يتكوّن منه الموقع. بعد ثلاث دقائق من رفع ناجح، يُحذف كل ما في تلك القائمة ولم يُعِد البناء الجديد كتابته. ثلاث دقائق أطول من 60 ثانية التي يمكن أن تُخزَّن فيها الصفحة في الحافة والمتصفح، فالزائر الذي ما زال يحمل الصفحة القديمة يجد الأصول التي تسمّيها.
4. إن شككت، فلا تحذف شيئاً. إذا فشلت قائمة ما قبل الرفع، لا يُحذف شيء. الملفات المتبقية غير ضارة، وإعادة النشر التالية تنظفها. فالحذف دون معرفة ما كان موجوداً هو ما يُفرغ الموقع.

الرفع الفاشل يترك الآن الموقع السابق كما كان تماماً.

اختبرنا هذا من طرف إلى طرف محلياً، باستخدام سكربت الرفع الفعلي ومسار الرفع الفعلي وخدمة التخزين الفعلية، مع زوّار يصلون وذاكرة الحافة الخاصة بهم فارغة. مع الكود القديم، كانت 55 من 91 زيارة معطوبة أثناء إعادة النشر، و61 من 92 أثناء رفع فاشل. مع الكود الجديد، كان العدد 0 عبر نحو 3,500 زيارة تغطي المسارين، ورفعاً فاشلاً، والنشر الذي تلاه، وحُذفت الملفات المتبقية بالضبط.

المشكلة الثانية: إعادة النشر تأخذ وقتاً طويلاً لتظهر

حتى عندما يسير الرفع بشكل جيد، كانت التغييرات تتأخر في الظهور. كانت الحافة تحتفظ بنسخة الصفحة 60 ثانية، ولكل ملف آخر يوماً كاملاً، وتخبر المتصفحات بالأمر نفسه. وقد تُظهر الملفات ذات الأسماء الثابتة، مثل logo.png أو خط أو أي شيء من مجلد public/، النسخة القديمة حتى يوماً كاملاً بعد إعادة النشر.

الإصلاح: نسخ الملفات تحت رقم البناء

عندما تسأل الحافة واجهة برمجتنا عن مكان الموقع، تتضمن الإجابة الآن علامة بناء تتغير في كل مرة يصل فيها نشر. وتحفظ الحافة نسخها تحت تلك العلامة. لذلك يصبح النشر مجموعة جديدة كاملة من مفاتيح التخزين المؤقت بمجرد انتهاء مهلة البحث البالغة 30 ثانية في الحافة. النسخ القديمة لا يُعثر عليها مرة أخرى أبداً، فتستطيع الحافة الاحتفاظ بالنسخ ليوم كامل دون أن تقدّم أي نسخة بعد النشر الذي استبدلها.

ويحصل المتصفح على قاعدتين مختلفتين:

• مخرجات البناء ذات الهاش، مثل الملفات assets/index-CzLcxDO8.js التي يتغير اسمها كلما تغير المحتوى، تُخزَّن لسنة وتوسم بأنها ثابتة (immutable). ولا يمكن أن تكون قديمة تحت هذا الاسم أبداً.
• كل ما عدا ذلك، أي الصفحات والملفات ذات الأسماء الثابتة مثل الشعار، يُوسم بـ no-cache، وهو يعني «تحقق قبل الاستخدام». إذا لم يتغير شيء، تكون الإجابة 304 Not Modified صغيرة بلا محتوى، بعد أن أصبحنا نحترم فحص If-None-Match من المتصفح.

التمييز بين الاثنين يحتاج عناية: ملف منسوخ من public/assets/ يحتفظ باسمه، وتخزين assets/logo.png لسنة كاملة سيثبّت الشعار القديم لسنة. لذلك لا يُعدّ الملف ذا هاش إلا إذا كان في مجلد مخرجات البناء و كان اسمه يحتوي على مقطع يشبه الهاش، لا كلمة عادية.

محلياً، ظهرت الصفحة والشعار الجديدان بعد 6 ثوانٍ من وصول النشر إلى الحياة. قبل ذلك كانت 60 ثانية للصفحة ويوماً كاملاً للشعار.

إصلاحان أصغر على الطريق

• صفحات فارغة من طلبات HEAD. طلب HEAD يطلب ترويسات الصفحة دون محتواها. كنا نخزّن تلك الاستجابات الفارغة، فيحصل الزائر التالي لتلك الصفحة على صفحة فارغة. لم تعد استجابات HEAD تُخزَّن.
• صفحة حقيقية لـ«لا يوجد شيء هنا». كان العنوان الذي لا يحتوي على تطبيق يعرض نصاً عادياً بعبارة «This published app is offline or the link was not found» مع رمز خطأ 502. الآن يحصل على صفحة لائقة، «There's no app here»، مع حالة 404 ورابط للعودة إلى Mythex لمالك الموقع. والنطاقات المخصصة غير المعروفة تحصل على الصفحة نفسها.

ما الذي استخلصناه

• الترتيب جزء من الصحة. الملفات نفسها إذا رُفعت بترتيب مختلف هي الفرق بين موقع معطوب وموقع يعمل.
• احذف متأخراً، وما تعرفه فقط. الحذف بالاعتماد على قائمة أُخذت قبل الرفع آمن، أما إفراغ مجلد والأمل في اكتمال الرفع فليس آمناً.
• خزّن حسب الإصدار لا حسب الوقت. أوقات انتهاء الصلاحية تخمين حول متى يتغير المحتوى. أما مفتاح يتغير مع البناء فهو حقيقة.

ذو صلة: تطبيقك المنشور يبقى متاحاً أثناء إعادة نشره. ومزيد عن النشر في الوثائق.