Static ဆိုဒ်များသည် ပြန် publish နေစဉ်လည်း ဆက်ရှိနေသည်

Mythex တွင် static ဆိုဒ်ကို ပြန် publish လုပ်ရာတွင် အရင်ဆုံး live ဖိုင်များကို ဖျက်ပြီးမှ အသစ် build ကို တင်သည်။ Upload ကြာသည့် အချိန်အတွင်း အချို့သော ဧည့်သည်များသည် 404 စာမျက်နှာ သို့မဟုတ် script များ ပျောက်နေသော စာမျက်နှာကို ရရှိခဲ့သည်။ Upload ကျရှုံးလျှင် ဆိုဒ်သည် ဗလာ သို့မဟုတ် တစ်စိတ်တစ်ပိုင်း အသစ်ဖြစ်နေနိုင်သည်။ ယခု အသစ် build ကို ဟောင်းအပေါ် ရေးထည့်ပြီး စာမျက်နှာများကို နောက်ဆုံး တင်သည်၊ ကျန်နေသော ဖိုင်များကို မိနစ်အနည်းငယ်နောက်မှ ဖယ်ရှားသည်။ ထို့အပြင် ပြန် publish လုပ်ခြင်းသည် တစ်မိနစ်အစား စက္ကန့်အနည်းငယ်အတွင်း ပေါ်လာပြီး logo ကဲ့သို့ ဖိုင်များအတွက်ဆိုလျှင် နေ့တစ်ရက်အထိ မစောင့်ရပါ။

Static ဆိုဒ်ကို ဘယ်လို serve လုပ်သလဲ

Static ဆိုဒ်ဆိုသည်မှာ ဖိုင်များသာ ဖြစ်သည်: HTML စာမျက်နှာများ၊ JavaScript၊ CSS၊ ပုံများ။ Mythex တွင် publish လုပ်သောအခါ ကျွန်ုပ်တို့က build လုပ်ပြီး output ကို သင့်ဆိုဒ်အတွက် folder တစ်ခုအောက်ရှိ object storage သို့ တင်သည်။ ထို့နောက် edge network မှတစ်ဆင့် serve လုပ်သည်။ Edge ဆိုသည်မှာ ဧည့်သည်များနှင့် နီးသော server များဖြစ်ပြီး storage မှ ဖိုင်များကို ယူကာ အချိန်အနည်းငယ် မိတ္တူ သိမ်းထားသည်။ (အကြောင်းအရာ မသိသေးပါက CDN ဆိုသည်မှာ ဘာလဲ လမ်းညွှန်ကို ကြည့်ပါ။)

အမှား နှစ်ခု ရှိခဲ့သည်: ပြန် publish လုပ်စဉ် ဖိုင်များ ပြောင်းသော အစီအစဉ်၊ နှင့် ဟောင်းမိတ္တူများကို ဘယ်လောက်ကြာ သိမ်းထားသလဲ ဆိုသည်။

ပြဿနာ ၁: Upload က ဆိုဒ်ကို အရင်ဗလာဖြစ်စေသည်

ပြန် publish လုပ်သောအခါ ဆိုဒ် folder ရှိ အရာအားလုံးကို ဖျက်ပြီး အသစ် build ကို တင်သည်။ Upload ကြာသမျှ (ကျွန်ုပ်တို့၏ local test တွင် ဖိုင် ၂၅၀ ရှိ ဆိုဒ်အတွက် ၁၂ စက္ကန့်) edge တွင် cache မရှိသော request ရရှိသော ဧည့်သည်သည် 404 သို့မဟုတ် scripts ၏ 404 ပါသော HTML စာမျက်နှာကို ရရှိသည်။

Upload ကျရှုံးလျှင် ပိုဆိုးသည်။ Folder ဗလာဖြစ်သွားပြီး upload path နှစ်ခုအနက် တစ်ခုတွင် index.html အသစ်သည် ကျရှုံးသော ဖိုင်ထက် အရင် ရောက်သွားနိုင်သည်။ ကျရှုံးဟု အစီရင်ခံထားသော publish သည် တစ်စိတ်တစ်ပိုင်း အသစ်ဆိုဒ်ကို live ထားနိုင်သည်။

ဖြေရှင်းချက်: ရေးထည့်ပါ၊ စာမျက်နှာများ နောက်ဆုံး၊ ကျန်သည်များ နောက်မှ ဖျက်ပါ

1. အရင်မဖျက်ပါနှင့်။ အသစ် build ကို ဟောင်းအပေါ် တင်သည်။
2. Assets များ စာမျက်နှာများထက် အရင်။ စာမျက်နှာသည် ၎င်းလိုအပ်သော scripts နှင့် styles ကို နာမည်ဖြင့် ညွှန်သဖြင့် စာမျက်နှာများကို နောက်ဆုံး တင်သည်။ အသစ် စာမျက်နှာများ မရောက်မချင်း ဧည့်သည်သည် ဟောင်းစာမျက်နှာကို ရရှိမည်။ ထို စာမျက်နှာက ဟောင်း assets ကို ညွှန်ပြပြီး ထို assets များ ရှိနေသေးသည်။ စာမျက်နှာအသစ်များ ရောက်သောအခါ ၎င်းတို့ ညွှန်ပြသော assets အသစ်များက ရှိနှင့်ပြီးဖြစ်သည်။
3. ကျန်နေသော ဖိုင်များကို နောက်မှ ဖယ်ရှားပါ။ Upload မတိုင်မီ ဆိုဒ်ကို ဖွဲ့စည်းထားသော ဖိုင်များ စာရင်းကို ယူသည်။ Upload အောင်မြင်ပြီး သုံးမိနစ်အကြာတွင် ထိုစာရင်းထဲမှ အသစ် build က ပြန်မရေးထားသော ဖိုင်များကို ဖျက်သည်။ သုံးမိနစ်သည် edge နှင့် browser တွင် စာမျက်နှာ cache လုပ်နိုင်သော ၆၀ စက္ကန့်ထက် ရှည်သည်။ ထို့ကြောင့် ဟောင်းစာမျက်နှာကို ကိုင်ထားသော ဧည့်သည်သည် ၎င်းညွှန်ပြသော assets ကို ရှာတွေ့နိုင်သည်။
4. သံသယရှိလျှင် ဘာမှမဖျက်ပါနှင့်။ Upload မတိုင်မီ စာရင်းယူခြင်း မအောင်မြင်လျှင် ဘာမှ prune မလုပ်ပါ။ ကျန်နေသော ဖိုင်များက အန္တရာယ်မရှိပါ၊ နောက် publish တွင် ရှင်းသွားမည်။ ဘာရှိသည်ကို မသိဘဲ ဖျက်ခြင်းက ဆိုဒ်ကို ဗလာဖြစ်စေသည်။

Upload ကျရှုံးပါက ယခင် ဆိုဒ်သည် အတိအကျ ယခင်အတိုင်း ကျန်ရစ်သည်။

ကျွန်ုပ်တို့သည် ဤအရာကို local တွင် အဆုံးမှအဆုံး စမ်းသပ်ခဲ့သည်။ Upload script အစစ်၊ upload route အစစ်နှင့် storage serving ကို သုံးပြီး edge cache အေးစက်နေသော ဧည့်သည်များဖြင့် စမ်းခဲ့သည်။ ဟောင်းကုဒ်ဖြင့် ပြန် publish စဉ် ၉၁ ခုအနက် ၅၅ ခု နှင့် ကျရှုံးစဉ် ၉၂ ခုအနက် ၆၁ ခု ၏ ဝင်ရောက်မှုများ ပျက်ခဲ့သည်။ ကုဒ်အသစ်ဖြင့် upload path နှစ်ခု၊ ကျရှုံးသော upload နှင့် ၎င်းနောက်ပိုင်း publish အားလုံးကို ဖုံးလွှမ်းသော ဧည့်သည် ၃,၅၀၀ ခန့်တွင် ၀ ခု ပျက်ခဲ့ပြီး ကျန်နေသော ဖိုင်များသာ ဖယ်ရှားခဲ့သည်။

ပြဿနာ ၂: ပြန် publish လုပ်ခြင်း ပြသရန် ကြာခဲ့သည်

Upload ကောင်းစွာ ပြီးသော်လည်း ပြောင်းလဲမှုများ ပေါ်ရန် နှေးသည်။ Edge သည် စာမျက်နှာကို ၆၀ စက္ကန့်၊ အခြားဖိုင်အားလုံးကို တစ်ရက် မိတ္တူသိမ်းထားပြီး browser ကိုလည်း ထိုနည်းအတိုင်း ပြောခဲ့သည်။ logo.png၊ font သို့မဟုတ် public/ folder မှ ဖိုင်များကဲ့သို့ နာမည်ပုံသေ ဖိုင်များသည် ပြန် publish ပြီးနောက် တစ်ရက်အထိ ဟောင်းဗားရှင်း ပြနိုင်သည်။

ဖြေရှင်းချက်: Build အောက်တွင် ဖိုင် မိတ္တူများ

Edge က API ကို ဆိုဒ်ရှိရာ မေးသောအခါ ဖြေကြားချက်တွင် publish တိုင်း ပြောင်းသော build marker ပါဝင်သည်။ Edge သည် မိတ္တူများကို ထို marker အောက်တွင် သိမ်းသည်။ ထို့ကြောင့် edge ၏ ၃၀ စက္ကန့် lookup သက်တမ်းကုန်ချိန်တွင် publish တစ်ခုသည် cache key အသစ်အစုံ ဖြစ်လာသည်။ ဟောင်း မိတ္တူများကို ထပ်မတွေ့တော့ဘဲ edge သည် တစ်ရက်အထိ ထားနိုင်ပြီး ၎င်းကို အစားထိုးသော publish ပြီးနောက် ဟောင်းမိတ္တူကို ဘယ်တော့မှ မပေးတော့ပါ။

Browser အတွက် စည်းမျဉ်း နှစ်ခု ရှိသည်:

• Hash ပါသော build output: assets/index-CzLcxDO8.js ကဲ့သို့ အမည်သည် အကြောင်းအရာ ပြောင်းလျှင် ပြောင်းသော ဖိုင်များကို တစ်နှစ်အထိ cache လုပ်ပြီး immutable ဟု မှတ်သည်။ ထိုအမည်ဖြင့် ဘယ်တော့မှ ဟောင်းမဖြစ်နိုင်ပါ။
• အခြားအရာအားလုံး: စာမျက်နှာများနှင့် logo ကဲ့သို့ နာမည်ပုံသေ ဖိုင်များကို no-cache ဟု မှတ်သည်။ ၎င်းသည် "အသုံးမပြုမီ စစ်ဆေးပါ" ဟု အဓိပ္ပာယ်ရသည်။ ဘာမှ မပြောင်းလဲလျှင် body မပါသော အရွယ်အစားသေးသော 304 Not Modified ပြန်သည်။ ယခု browser ၏ If-None-Match စစ်ဆေးမှုကို လေးစားသောကြောင့် ဖြစ်သည်။

နှစ်မျိုးကို ခွဲခြားရာတွင် ဂရုစိုက်ရသည်: public/assets/ မှ ကူးထားသော ဖိုင်သည် ကိုယ်ပိုင်အမည်ကို ထိန်းထားသည်၊ assets/logo.png ကို တစ်နှစ် cache လုပ်ပါက ဟောင်း logo ကို တစ်နှစ် ကပ်နေစေမည်။ ထို့ကြောင့် ဖိုင်တစ်ခုသည် build output folder ထဲတွင် ရှိပြီး အမည်တွင် ဟက်ရှ်ဟု ထင်ရသော အပိုင်းတစ်ခုပါမှသာ hash ပါသည်ဟု ရေတွက်သည်၊ ပုံမှန်စကားလုံးမဟုတ်ပါ။

ဒေသခံ စမ်းသပ်မှုတွင် စာမျက်နှာအသစ်နှင့် logo ကို publish live ဖြစ်ပြီးနောက် ၆ စက္ကန့် အကြာတွင် မြင်ရသည်။ ယခင် ၆၀ စက္ကန့် (စာမျက်နှာ) နှင့် တစ်ရက် (logo) ဖြစ်ခဲ့သည်။

အသေးစား ပြင်ဆင်ချက် နှစ်ခု

• HEAD request မှ ဗလာစာမျက်နှာများ။ HEAD request သည် body မပါဘဲ header များသာ တောင်းသည်။ ထိုဗလာ တုံ့ပြန်ချက်များကို cache လုပ်နေသဖြင့် နောက်ဧည့်သည်သည် ဗလာစာမျက်နှာ ရရှိခဲ့သည်။ HEAD တုံ့ပြန်ချက်များကို ယခု cache မလုပ်တော့ပါ။
• "ဘာမှမရှိ" အတွက် စစ်မှန်သော စာမျက်နှာ။ အက်ပ်မရှိသော လိပ်စာသည် 502 error code ဖြင့် "ဤ published app offline ဖြစ်နေသည် သို့မဟုတ် link မတွေ့ပါ" ဟု plain text ပြခဲ့သည်။ ယခု "ဤနေရာတွင် အက်ပ်မရှိပါ" ဟု 404 status ဖြင့် ပြပြီး ပိုင်ရှင်အတွက် Mythex သို့ ပြန်သွားရန် နည်းလမ်းပါသော စာမျက်နှာ ပြသည်။ မသိသော custom domain များလည်း တူညီသော စာမျက်နှာ ရရှိသည်။

ကျွန်ုပ်တို့ ရရှိခဲ့သည့်အရာ

• အစီအစဉ်သည် မှန်ကန်မှု၏ အစိတ်အပိုင်း ဖြစ်သည်။ တူညီသော ဖိုင်များကို အခြားအစီအစဉ်ဖြင့် upload လုပ်ခြင်းက ဆိုဒ်ပျက်ခြင်းနှင့် အလုပ်လုပ်ခြင်း ကွာခြားစေသည်။
• နောက်မှဖျက်ပါ၊ သိသည်များကိုသာ ဖျက်ပါ။ Upload မတိုင်မီ ယူထားသော စာရင်းဖြင့် prune လုပ်ခြင်းသည် ဘေးကင်းသည်။ Folder ကို ဗလာလုပ်ပြီး upload ပြီးမည်ဟု မျှော်လင့်ခြင်းသည် မဟုတ်ပါ။
• အချိန်ဖြင့်မဟုတ်ဘဲ ဗားရှင်းဖြင့် cache လုပ်ပါ။ သက်တမ်းအချိန်များသည် အကြောင်းအရာ ပြောင်းသော အချိန်ကို ခန့်မှန်းခြင်း ဖြစ်သည်။ Build နှင့်အတူ ပြောင်းသော key သည် အမှန်တရား ဖြစ်သည်။

ဆက်စပ်: သင့် publish လုပ်ထားသော အက်ပ်သည် ပြန် publish နေစဉ်လည်း ဆက်ရှိနေသည်။ Publish အကြောင်း နောက်ထပ် docs တွင် ရှိသည်။