Static Sites اب دوبارہ publish ہوتے وقت بھی چلتی رہتی ہیں

Mythex پر static site کو دوبارہ publish کرنے سے پہلے live فائلیں حذف ہوتی تھیں اور پھر نئی build upload ہوتی تھی، اس لیے upload کے دوران کچھ visitors کو 404 صفحہ ملتا تھا یا ایسا صفحہ جس کے scripts غائب ہوتے تھے۔ ناکام upload سائٹ کو خالی یا آدھی نئی چھوڑ سکتا تھا۔ اب نئی build پرانی کے اوپر لکھی جاتی ہے، صفحات سب سے آخر میں، اور بچ جانے والی فائلیں کچھ منٹ بعد ہٹ جاتی ہیں۔ دوسری تبدیلی سے دوبارہ publish کرنا چند سیکنڈ میں نظر آتا ہے، پہلے ایک منٹ لگتا تھا، یا logo جیسی فائلوں کے لیے ایک دن تک۔

Static site کیسے serve ہوتی ہے

Static site وہ ہے جو صرف فائلیں ہیں: HTML صفحات، JavaScript، CSS، تصاویر۔ جب آپ Mythex پر ایسی سائٹ publish کرتے ہیں تو ہم اسے build کرتے ہیں، اس کا آؤٹ پٹ object storage میں آپ کی سائٹ کے فولڈر کے تحت upload کرتے ہیں، اور اسے ایک edge network کے ذریعے serve کرتے ہیں: یہ سرور آپ کے visitors کے قریب ہوتے ہیں، storage سے فائلیں لاتے ہیں اور کچھ دیر کے لیے ان کی کاپیاں رکھتے ہیں۔ (اگر یہ نیا ہے تو ہماری گائیڈ CDN کیا ہے یہ خیال سمجھاتی ہے۔)

دو چیزیں غلط تھیں: republish کے دوران فائلیں بدلنے کی ترتیب، اور پرانی کاپیاں کتنی دیر رکھی جاتی تھیں۔

مسئلہ 1: upload نے پہلے سائٹ خالی کر دی

Republish پہلے اس سائٹ کے فولڈر کی ہر چیز حذف کرتا تھا، پھر نئی build upload کرتا تھا۔ جب تک upload چلتا، یعنی ہماری مقامی جانچ میں 250 فائلوں کی سائٹ کے لیے 12 سیکنڈ، جس visitor کی درخواست edge پر cache میں نہیں تھی اسے 404 ملتا تھا، یا ایسا HTML صفحہ جس کے scripts 404 دیتے تھے۔

ناکام upload اس سے بھی برا تھا۔ فولڈر پہلے ہی خالی ہو چکا تھا، اور upload کے دو راستوں میں سے ایک پر نیا index.html اس فائل سے پہلے لگ سکتا تھا جو ناکام ہوئی۔ ناکام بتائی گئی publish کے بعد بھی آدھی نئی سائٹ live رہ سکتی تھی۔

حل: اوپر لکھیں، صفحات آخر میں، بچی ہوئی فائلیں بعد میں

1. پہلے حذف نہ کریں۔ نئی build پرانی کے اوپر upload ہوتی ہے۔
2. Assets صفحات سے پہلے۔ صفحہ بتاتا ہے کہ اسے کون سے scripts اور styles چاہئیں، اس لیے صفحات سب سے آخر میں جاتے ہیں۔ نئے صفحات لگنے تک visitor کو پرانا صفحہ ملتا ہے، جو پرانے assets کا نام لیتا ہے، اور وہ assets ابھی موجود ہیں۔ جب نئے صفحات لگتے ہیں تو جن نئے assets کا وہ نام لیتے ہیں وہ پہلے ہی جگہ پر ہوتے ہیں۔
3. بچی ہوئی فائلیں بعد میں ہٹائیں۔ Upload سے پہلے ہم فہرست بناتے ہیں کہ سائٹ کن فائلوں سے بنی ہے۔ کامیاب upload کے تین منٹ بعد، اس فہرست میں جو کچھ نئی build نے دوبارہ نہیں لکھا وہ حذف ہو جاتا ہے۔ تین منٹ اس 60 سیکنڈ سے لمبے ہیں جن تک صفحہ edge اور browser میں cache ہو سکتا ہے، اس لیے پرانا صفحہ رکھنے والا visitor بھی اس کے assets پا سکتا ہے۔
4. شک ہو تو کچھ حذف نہ کریں۔ اگر upload سے پہلے کی فہرست نہ بن سکے تو کچھ بھی prune نہیں ہوتا۔ بچی ہوئی فائلیں نقصان دہ نہیں، اور اگلی publish انہیں صاف کر دیتی ہے۔ یہ جانے بغیر حذف کرنا ہی وہ طریقہ ہے جس سے سائٹ خالی ہو جاتی ہے۔

اب ناکام upload بھی پچھلی سائٹ کو بالکل ویسا ہی چھوڑ دیتا ہے جیسی وہ تھی۔

ہم نے یہ سب شروع سے آخر تک مقامی طور پر جانچا، اصل upload script، اصل upload route اور storage serving کے ساتھ، اور ایسے visitors کے ساتھ جن کا edge cache ٹھنڈا تھا۔ پرانے کوڈ کے ساتھ republish کے دوران 91 میں سے 55 visits خراب ہوئیں، اور ناکام republish کے دوران 92 میں سے 61۔ نئے کوڈ کے ساتھ تقریباً 3,500 visits میں 0 خراب ہوئیں، جن میں دونوں upload راستے، ایک ناکام upload، اور اس کے بعد کی publish شامل تھیں، اور بالکل وہی بچی ہوئی فائلیں prune ہوئیں۔

مسئلہ 2: republish دکھنے میں بہت دیر لگاتا تھا

اگر upload ٹھیک ہو جاتا تب بھی تبدیلیاں دیر سے نظر آتی تھیں۔ Edge کسی صفحے کی کاپی 60 سیکنڈ اور باقی ہر فائل کی ایک دن تک رکھتا تھا، اور browsers کو بھی یہی بتاتا تھا۔ مقررہ نام والی فائلیں، جیسے logo.png، کوئی font، یا public/ فولڈر کی کوئی بھی چیز، republish کے بعد ایک دن تک پرانا ورژن دکھا سکتی تھیں۔

حل: build کے نیچے فائل کاپیاں

جب edge ہماری API سے پوچھتا ہے کہ سائٹ کہاں ہے، تو جواب میں اب ایک build marker شامل ہوتا ہے جو ہر publish کے لینڈ ہونے پر بدلتا ہے۔ Edge اپنی کاپیاں اسی marker کے تحت رکھتا ہے۔ اس لیے جیسے ہی edge کی 30 سیکنڈ کی lookup ختم ہوتی ہے، ایک publish cache keys کا بالکل نیا سیٹ بن جاتی ہے۔ پرانی کاپیاں دوبارہ کبھی نہیں ملتیں، اس لیے edge کاپیاں ایک دن تک رکھ سکتا ہے بغیر کبھی ایسی کاپی serve کیے جو اس publish کے بعد پرانی ہو چکی ہو جس نے اسے بدلا۔

Browsers کے لیے دو مختلف اصول ہیں:

• Hashed build آؤٹ پٹ، جیسے assets/index-CzLcxDO8.js، جن کا نام ہر بار بدلتا ہے جب مواد بدلتا ہے، ایک سال کے لیے cache ہوتا ہے اور immutable نشان ہوتا ہے۔ اس نام کے تحت یہ کبھی پرانا نہیں ہو سکتا۔
• باقی سب، یعنی صفحات اور مقررہ نام والی فائلیں جیسے logo، no-cache نشان ہوتی ہیں، جس کا مطلب ہے “استعمال سے پہلے چیک کرو”۔ اگر کچھ نہیں بدلا تو جواب ایک چھوٹا 304 Not Modified ہوتا ہے جس میں body نہیں ہوتی، اب جب ہم browser کی If-None-Match جانچ کا احترام کرتے ہیں۔

ان دونوں کو الگ کرنے میں احتیاط چاہیے: public/assets/ سے کاپی ہونے والی فائل اپنا نام رکھتی ہے، اور assets/logo.png کو ایک سال کے لیے cache کرنا پرانا logo ایک سال کے لیے جما دیتا۔ اس لیے کوئی فائل تبھی hashed شمار ہوتی ہے جب وہ کسی build آؤٹ پٹ فولڈر میں ہو اور اس کے نام میں کوئی ایسا حصہ ہو جو hash جیسا لگے، عام لفظ جیسا نہیں۔

مقامی طور پر، نیا صفحہ اور logo publish live ہونے کے 6 سیکنڈ بعد نظر آ گئے۔ پہلے صفحے کے لیے 60 سیکنڈ اور logo کے لیے ایک دن لگتا تھا۔

راستے میں دو چھوٹی اصلاحات

• HEAD درخواستوں سے خالی صفحات۔ HEAD درخواست صرف صفحے کے headers مانگتی ہے، body کے بغیر۔ ہم یہ خالی جوابات cache کر رہے تھے، تو اگلے visitor کو خالی صفحہ ملتا تھا۔ اب HEAD جوابات cache نہیں ہوتے۔
• “یہاں کچھ نہیں” کے لیے ایک حقیقی صفحہ۔ جس پتے پر کوئی ایپ نہ ہو وہ پہلے سادہ متن میں “This published app is offline or the link was not found” اور 502 error code دیتا تھا۔ اب اسے ایک مناسب صفحہ ملتا ہے، “یہاں کوئی ایپ نہیں ہے”، 404 status کے ساتھ اور مالک کے لیے Mythex پر واپس جانے کا راستہ۔ نامعلوم custom domains کو بھی یہی صفحہ ملتا ہے۔

ہم نے اس سے کیا سیکھا

• ترتیب بھی درستگی کا حصہ ہے۔ وہی فائلیں مختلف ترتیب سے upload ہوں تو فرق ایک ٹوٹی ہوئی اور ایک کام کرتی سائٹ کا ہوتا ہے۔
• دیر سے حذف کریں، اور صرف وہی جو آپ جانتے ہیں۔ Upload سے پہلے لی گئی فہرست کے ساتھ prune کرنا محفوظ ہے؛ فولڈر خالی کر کے امید رکھنا کہ upload مکمل ہو جائے، محفوظ نہیں۔
• وقت سے نہیں، ورژن سے cache کریں۔ Expiry کے اوقات اس بارے میں اندازہ ہیں کہ مواد کب بدلتا ہے۔ جو key build کے ساتھ بدلتی ہے وہ ایک حقیقت ہے۔

متعلقہ: آپ کی published ایپ دوبارہ publish کرتے وقت بھی چلتی رہتی ہے۔ Publishing کے بارے میں مزید docs میں ہے۔