സ്റ്റാറ്റിക് സൈറ്റുകൾ വീണ്ടും പബ്ലിഷ് ചെയ്യുമ്പോഴും ഇപ്പോൾ ലൈവായി തുടരുന്നു

Mythex-ൽ സ്റ്റാറ്റിക് സൈറ്റ് വീണ്ടും പബ്ലിഷ് ചെയ്യുമ്പോൾ, പുതിയ ബിൽഡ് അപ്‌ലോഡ് ചെയ്യുന്നതിന് മുമ്പ് ലൈവ് ഫയലുകൾ ആദ്യം ഇല്ലാതാക്കപ്പെടുമായിരുന്നു. അതുകൊണ്ട് അപ്‌ലോഡ് നടക്കുന്ന സമയത്ത് ചില സന്ദർശകർക്ക് 404 പേജോ സ്ക്രിപ്റ്റുകൾ നഷ്ടപ്പെട്ട പേജോ കാണേണ്ടിവന്നു. പരാജയപ്പെട്ട അപ്‌ലോഡ് സൈറ്റിനെ ശൂന്യമാക്കുകയോ പകുതി പുതിയതാക്കുകയോ ചെയ്യാമായിരുന്നു. ഇപ്പോൾ പുതിയ ബിൽഡ് പഴയതിന് മുകളിൽ എഴുതുന്നു, പേജുകൾ അവസാനം, ബാക്കിയുള്ള ഫയലുകൾ കുറച്ച് മിനിറ്റുകൾക്ക് ശേഷം നീക്കം ചെയ്യുന്നു. രണ്ടാമത്തെ പരിഹാരം, റിപ്പബ്ലിഷ് ഒരു മിനിറ്റിനുപകരം സെക്കൻഡുകൾക്കുള്ളിൽ കാണിക്കുന്നു — ലോഗോ പോലുള്ള ഫയലുകൾക്ക് ഒരു ദിവസം വരെ എടുക്കാം.

സ്റ്റാറ്റിക് സൈറ്റ് എങ്ങനെ സേവനം നൽകുന്നു

സ്റ്റാറ്റിക് സൈറ്റ് എന്നത് ഫയലുകൾ മാത്രമുള്ള ഒന്നാണ്: HTML പേജുകൾ, JavaScript, CSS, ചിത്രങ്ങൾ. Mythex-ൽ ഇത് പബ്ലിഷ് ചെയ്യുമ്പോൾ ഞങ്ങൾ അതിനെ ബിൽഡ് ചെയ്യുന്നു, ഔട്ട്പുട്ട് നിങ്ങളുടെ സൈറ്റിനുള്ള ഒരു ഫോൾഡറിന് കീഴിൽ ഒബ്ജക്റ്റ് സ്റ്റോറേജിലേക്ക് അപ്‌ലോഡ് ചെയ്യുന്നു, തുടർന്ന് ഒരു എഡ്ജ് നെറ്റ്‌വർക്ക് വഴി സേവനം നൽകുന്നു — സന്ദർശകർക്ക് അടുത്തുള്ള സെർവറുകൾ, അവ സ്റ്റോറേജിൽ നിന്ന് ഫയലുകൾ എടുത്ത് കുറച്ചുനേരം പകർപ്പുകൾ സൂക്ഷിക്കുന്നു. (ഇതു പുതിയതാണെങ്കിൽ, CDN എന്താണ് എന്നതിനെക്കുറിച്ചുള്ള ഞങ്ങളുടെ ഗൈഡ് ഈ ആശയം വിശദീകരിക്കുന്നു.)

രണ്ട് കാര്യങ്ങളാണ് തെറ്റായിരുന്നത്: ഒരു റിപ്പബ്ലിഷ് ഫയലുകൾ മാറ്റുന്ന ക്രമം, പഴയ പകർപ്പുകൾ എത്രനേരം സൂക്ഷിച്ചു എന്നത്.

പ്രശ്നം 1: അപ്‌ലോഡ് സൈറ്റിനെ ആദ്യം ശൂന്യമാക്കി

ഒരു റിപ്പബ്ലിഷ് സൈറ്റിന്റെ ഫോൾഡറിലെ എല്ലാം ഇല്ലാതാക്കി, പിന്നെ പുതിയ ബിൽഡ് അപ്‌ലോഡ് ചെയ്യും. അപ്‌ലോഡിന് എടുത്ത സമയം മുഴുവൻ — ഞങ്ങളുടെ ലോക്കൽ ടെസ്റ്റിൽ 250 ഫയലുള്ള സൈറ്റിന് 12 സെക്കൻഡ് — എഡ്ജിൽ കാഷ് ചെയ്യപ്പെടാത്ത അഭ്യർത്ഥനയുള്ള സന്ദർശകന് 404 അല്ലെങ്കിൽ സ്ക്രിപ്റ്റുകൾ 404 നൽകുന്ന HTML പേജ് ലഭിച്ചു.

പരാജയപ്പെട്ട അപ്‌ലോഡ് കൂടുതൽ മോശമായിരുന്നു. ഫോൾഡർ ഇതിനകം ശൂന്യമായിരുന്നു, രണ്ട് അപ്‌ലോഡ് വഴികളിൽ ഒന്നിൽ പുതിയ index.html പരാജയപ്പെട്ട ഫയലിന് മുമ്പ് എത്താമായിരുന്നു. പരാജയം എന്ന് റിപ്പോർട്ട് ചെയ്ത ഒരു പബ്ലിഷ് പകുതി പുതിയ സൈറ്റ് ലൈവായി വിട്ടേക്കാമായിരുന്നു.

പരിഹാരം: മുകളിൽ എഴുതുക, പേജുകൾ അവസാനം, ബാക്കി പിന്നീട്

1. ആദ്യം ഇല്ലാതാക്കരുത്. പുതിയ ബിൽഡ് പഴയതിന് മുകളിൽ അപ്‌ലോഡ് ചെയ്യുന്നു.
2. അസറ്റുകൾ പേജുകൾക്ക് മുമ്പ്. ഒരു പേജ് അതിന് വേണ്ട സ്ക്രിപ്റ്റുകളും സ്റ്റൈലുകളും പേരെടുത്ത് പറയുന്നു, അതിനാൽ പേജുകൾ അവസാനം അപ്‌ലോഡ് ചെയ്യുന്നു. പുതിയ പേജുകൾ എത്തുന്നതുവരെ സന്ദർശകർക്ക് പഴയ പേജ് കിട്ടും, അത് പഴയ അസറ്റുകളെ പേരെടുത്ത് പറയുന്നു, അവ ഇപ്പോഴും ഉണ്ട്. എത്തിയ ശേഷം, അവ പേരെടുത്ത് പറയുന്ന പുതിയ അസറ്റുകൾ ഇതിനകം സ്ഥാനത്താണ്.
3. ബാക്കിയുള്ളവ പിന്നീട് നീക്കം ചെയ്യുന്നു. അപ്‌ലോഡിന് മുമ്പ് സൈറ്റിൽ എന്തൊക്കെയുണ്ടെന്ന് ഞങ്ങൾ പട്ടികപ്പെടുത്തുന്നു. വിജയകരമായ അപ്‌ലോഡിന് മൂന്ന് മിനിറ്റിന് ശേഷം, ആ പട്ടികയിലുള്ളതും പുതിയ ബിൽഡ് വീണ്ടും എഴുതാത്തതുമായ എന്തും ഇല്ലാതാക്കുന്നു. മൂന്ന് മിനിറ്റ് എന്നത് എഡ്ജിലും ബ്രൗസറിലും ഒരു പേജ് കാഷ് ചെയ്യപ്പെടാവുന്ന 60 സെക്കൻഡിനേക്കാൾ കൂടുതലാണ്, അതിനാൽ പഴയ പേജ് കൈവശമുള്ള സന്ദർശകന് അത് പേരെടുത്ത് പറയുന്ന അസറ്റുകൾ കണ്ടെത്താം.
4. സംശയമുണ്ടെങ്കിൽ, ഒന്നും ഇല്ലാതാക്കരുത്. അപ്‌ലോഡിന് മുമ്പുള്ള പട്ടികയെടുക്കൽ പരാജയപ്പെട്ടാൽ, ഒന്നും വെട്ടിമാറ്റില്ല. ബാക്കി ഫയലുകൾ ദോഷകരമല്ല, അടുത്ത പബ്ലിഷ് അവ വൃത്തിയാക്കും. എന്തുണ്ടായിരുന്നു എന്നറിയാതെ ഇല്ലാതാക്കുന്നതാണ് സൈറ്റ് ശൂന്യമാകാൻ കാരണം.

പരാജയപ്പെട്ട അപ്‌ലോഡ് ഇപ്പോൾ മുമ്പത്തെ സൈറ്റിനെ കൃത്യമായി അതേപടി വിടുന്നു.

ഞങ്ങൾ ഇത് അവസാനം മുതൽ അവസാനം വരെ പ്രാദേശികമായി പരീക്ഷിച്ചു: യഥാർത്ഥ അപ്‌ലോഡ് സ്ക്രിപ്റ്റ്, യഥാർത്ഥ അപ്‌ലോഡ് റൂട്ട്, സ്റ്റോറേജ് സർവിംഗ്, തണുത്ത എഡ്ജ് കാഷ് ഉള്ള സന്ദർശകർ എന്നിവ ഉപയോഗിച്ച്. പഴയ കോഡ് ഉപയോഗിച്ച്, റിപ്പബ്ലിഷ് സമയത്ത് 91-ൽ 55 സന്ദർശനങ്ങൾ തകർന്നു, പരാജയപ്പെട്ടപ്പോൾ 92-ൽ 61. പുതിയ കോഡ് ഉപയോഗിച്ച്, രണ്ട് അപ്‌ലോഡ് വഴികൾ, ഒരു പരാജയപ്പെട്ട അപ്‌ലോഡ്, അതിന് ശേഷമുള്ള പബ്ലിഷ് എന്നിവ ഉൾക്കൊള്ളുന്ന ഏകദേശം 3,500 സന്ദർശനങ്ങളിൽ 0 തകർന്നു — കൃത്യമായി ബാക്കി ഫയലുകൾ മാത്രമേ നീക്കം ചെയ്യപ്പെട്ടുള്ളൂ.

പ്രശ്നം 2: റിപ്പബ്ലിഷ് കാണിക്കാൻ വളരെ സമയമെടുത്തു

അപ്‌ലോഡ് നന്നായി നടന്നപ്പോഴും മാറ്റങ്ങൾ കാണാൻ വൈകി. എഡ്ജ് ഒരു പേജിന്റെ പകർപ്പ് 60 സെക്കൻഡും മറ്റെല്ലാ ഫയലുകളുടെയും ഒരു ദിവസവും സൂക്ഷിച്ചു, ബ്രൗസറുകളോടും അങ്ങനെ ചെയ്യാൻ പറഞ്ഞു. logo.png, ഒരു ഫോണ്ട്, public/ ഫോൾഡറിൽ നിന്നുള്ള എന്തും പോലുള്ള നിശ്ചിത പേരുള്ള ഫയലുകൾ റിപ്പബ്ലിഷിന് ശേഷം ഒരു ദിവസം വരെ പഴയ പതിപ്പ് കാണിച്ചേക്കാം.

പരിഹാരം: ബിൽഡിന് കീഴിലുള്ള ഫയൽ പകർപ്പുകൾ

സൈറ്റ് എവിടെയാണെന്ന് എഡ്ജ് ഞങ്ങളുടെ API-യോട് ചോദിക്കുമ്പോൾ, ഉത്തരത്തിൽ ഇപ്പോൾ ഒരു ബിൽഡ് മാർക്കർ ഉൾപ്പെടുന്നു, അത് ഓരോ തവണ പബ്ലിഷ് എത്തുമ്പോഴും മാറുന്നു. എഡ്ജ് അതിന്റെ പകർപ്പുകൾ ആ മാർക്കറിന് കീഴിൽ ഫയൽ ചെയ്യുന്നു. അതിനാൽ എഡ്ജിന്റെ 30 സെക്കൻഡ് ലുക്കപ്പ് കാലഹരണപ്പെട്ടാൽ ഒരു പബ്ലിഷ് ഉടനെ പുതിയ കാഷ് കീകളുടെ പുതിയ കൂട്ടമായി മാറുന്നു. പഴയ പകർപ്പുകൾ പിന്നെ ഒരിക്കലും കണ്ടെത്തപ്പെടുന്നില്ല, അതിനാൽ അവയെ മാറ്റിയ പബ്ലിഷിനപ്പുറം ഒരിക്കലും പഴയത് നൽകാതെ എഡ്ജിന് ഒരു ദിവസം വരെ പകർപ്പുകൾ സൂക്ഷിക്കാം.

ബ്രൗസറുകൾക്ക് രണ്ട് വ്യത്യസ്ത നിയമങ്ങൾ ലഭിക്കുന്നു:

• ഹാഷ് ചെയ്ത ബിൽഡ് ഔട്ട്പുട്ട് — assets/index-CzLcxDO8.js പോലുള്ള ഫയലുകൾ, ഉള്ളടക്കം മാറുമ്പോൾ പേര് മാറുന്നവ — ഒരു വർഷത്തേക്ക് കാഷ് ചെയ്യുകയും മാറ്റമില്ലാത്തതായി (immutable) അടയാളപ്പെടുത്തുകയും ചെയ്യുന്നു. ആ പേരിൽ അത് ഒരിക്കലും പഴയതാകില്ല.
• മറ്റെല്ലാം — പേജുകളും logo പോലുള്ള നിശ്ചിത പേരുള്ള ഫയലുകളും — no-cache എന്ന് അടയാളപ്പെടുത്തുന്നു, അതായത് "ഉപയോഗിക്കുന്നതിന് മുമ്പ് പരിശോധിക്കുക". ഒന്നും മാറിയിട്ടില്ലെങ്കിൽ, ഉത്തരം ബോഡി ഇല്ലാത്ത ഒരു ചെറിയ 304 Not Modified ആണ്, ഇപ്പോൾ ബ്രൗസറിന്റെ If-None-Match പരിശോധനയെ ഞങ്ങൾ മാനിക്കുന്നതിനാൽ.

രണ്ടും വേർതിരിച്ചറിയാൻ ശ്രദ്ധ വേണം: public/assets/-ൽ നിന്ന് പകർത്തിയ ഫയൽ അതിന്റെ സ്വന്തം പേര് നിലനിർത്തുന്നു, assets/logo.png ഒരു വർഷത്തേക്ക് കാഷ് ചെയ്താൽ പഴയ logo ഒരു വർഷം പിടിച്ചുനിർത്തും. അതിനാൽ ഒരു ഫയൽ ഹാഷ് ചെയ്തതായി കണക്കാക്കുന്നത്, അത് ഒരു ബിൽഡ് ഔട്ട്പുട്ട് ഫോൾഡറിലാണെങ്കിലും അതിന്റെ പേരിൽ സാധാരണ വാക്ക് അല്ലാതെ ഹാഷ് പോലെ തോന്നുന്ന ഒരു ഭാഗം ഉണ്ടെങ്കിൽ മാത്രമാണ്.

പ്രാദേശികമായി, പുതിയ പേജും logo-യും പബ്ലിഷ് ലൈവായ ശേഷം 6 സെക്കൻഡിനുള്ളിൽ കാണാമായിരുന്നു. മുമ്പ്, പേജിന് 60 സെക്കൻഡും logo-യ്ക്ക് ഒരു ദിവസവുമായിരുന്നു.

വഴിയിൽ വന്ന രണ്ട് ചെറിയ പരിഹാരങ്ങൾ

• HEAD അഭ്യർത്ഥനകളിൽ നിന്നുള്ള ശൂന്യ പേജുകൾ. HEAD അഭ്യർത്ഥന ബോഡി ഇല്ലാതെ ഒരു പേജിന്റെ ഹെഡറുകൾ ചോദിക്കുന്നു. ആ ശൂന്യ മറുപടികൾ ഞങ്ങൾ കാഷ് ചെയ്തിരുന്നു, അതിനാൽ അടുത്ത സന്ദർശകന് ആ പേജ് ശൂന്യമായി കിട്ടി. HEAD മറുപടികൾ ഇനി കാഷ് ചെയ്യില്ല.
• "ഇവിടെ ഒന്നുമില്ല" എന്നതിന് ഒരു യഥാർത്ഥ പേജ്. ആപ്പില്ലാത്ത ഒരു വിലാസത്തിന് മുമ്പ് "This published app is offline or the link was not found" എന്ന സാധാരണ ടെക്സ്റ്റും 502 പിശക് കോഡും ലഭിച്ചിരുന്നു. ഇപ്പോൾ "There's no app here" എന്ന ശരിയായ പേജും 404 സ്റ്റാറ്റസും ഉടമയ്ക്ക് Mythex-ലേക്ക് മടങ്ങാനുള്ള വഴിയും ലഭിക്കുന്നു. അജ്ഞാത കസ്റ്റം ഡൊമെയ്‌നുകൾക്കും ഇതേ പേജ് ലഭിക്കുന്നു.

ഞങ്ങൾ എടുത്ത പാഠങ്ങൾ

• ക്രമം ശരിയാകലിന്റെ ഭാഗമാണ്. ഒരേ ഫയലുകൾ വ്യത്യസ്ത ക്രമത്തിൽ അപ്‌ലോഡ് ചെയ്താൽ തകർന്ന സൈറ്റും പ്രവർത്തിക്കുന്ന സൈറ്റും തമ്മിലുള്ള വ്യത്യാസമാകും.
• വൈകി ഇല്ലാതാക്കുക, അറിയാവുന്നത് മാത്രം. അപ്‌ലോഡിന് മുമ്പെടുത്ത പട്ടികയുപയോഗിച്ചുള്ള നീക്കം സുരക്ഷിതമാണ്; ഫോൾഡർ ശൂന്യമാക്കി അപ്‌ലോഡ് പൂർത്തിയാകുമെന്ന് പ്രതീക്ഷിക്കുന്നത് അല്ല.
• സമയം അനുസരിച്ചല്ല, പതിപ്പ് അനുസരിച്ച് കാഷ് ചെയ്യുക. കാലാവധി സമയങ്ങൾ ഉള്ളടക്കം എപ്പോൾ മാറുമെന്നതിനെക്കുറിച്ചുള്ള ഊഹമാണ്. ബിൽഡിനൊപ്പം മാറുന്ന ഒരു കീ ഒരു വസ്തുതയാണ്.

ബന്ധപ്പെട്ടത്: നിങ്ങളുടെ പബ്ലിഷ് ചെയ്ത ആപ്പ് റിപ്പബ്ലിഷ് ചെയ്യുമ്പോഴും ലൈവായി തുടരുന്നു. പബ്ലിഷിംഗിനെക്കുറിച്ച് കൂടുതൽ ഡോക്സിൽ.