સ્ટેટિક સાઇટ્સ હવે ફરી પ્રકાશિત થતી વખતે પણ ચાલુ રહે છે

Mythex પર સ્ટેટિક સાઇટને ફરી પ્રકાશિત કરતી વખતે પહેલાં લાઇવ ફાઇલો ડિલીટ થતી હતી, અને પછી નવો બિલ્ડ અપલોડ થતો હતો. તેથી અપલોડ ચાલે તે દરમિયાન કેટલાક મુલાકાતીઓને 404 પેજ મળતું, અથવા એવું પેજ મળતું જેની સ્ક્રિપ્ટ ગાયબ હોય. નિષ્ફળ અપલોડથી સાઇટ ખાલી થઈ જતી, અથવા અડધી નવી અને અડધી જૂની બની રહેતી. હવે નવો બિલ્ડ જૂના પર લખાય છે, પેજ સૌથી છેલ્લે જાય છે, અને બાકી રહેલી ફાઇલો થોડી મિનિટો પછી દૂર થાય છે. બીજો સુધારો એ છે કે ફરી પ્રકાશન એક મિનિટને બદલે સેકંડોમાં દેખાય છે. લોગો જેવી ફાઇલો માટે તે એક દિવસ સુધી લાગી શકતું હતું.

સ્ટેટિક સાઇટ કેવી રીતે સર્વ થાય છે

સ્ટેટિક સાઇટ એટલે માત્ર ફાઇલોનો સમૂહ: HTML પેજ, JavaScript, CSS અને ઇમેજ. Mythex પર તમે તેને પ્રકાશિત કરો ત્યારે અમે તેનો બિલ્ડ બનાવીએ છીએ, આઉટપુટ તમારી સાઇટના ફોલ્ડર હેઠળ ઓબ્જેક્ટ સ્ટોરેજમાં અપલોડ કરીએ છીએ, અને એજ નેટવર્ક દ્વારા સર્વ કરીએ છીએ. એજ નેટવર્ક એટલે મુલાકાતીઓની નજીકના સર્વર, જે સ્ટોરેજમાંથી ફાઇલો લાવે છે અને થોડા સમય માટે તેની નકલ રાખે છે. (જો આ તમારા માટે નવું હોય, તો CDN શું છે એ વિચાર સમજાવે છે.)

બે બાબતો ખોટી હતી: ફરી પ્રકાશનમાં ફાઇલો કઈ ક્રમમાં બદલાય છે, અને જૂની નકલો કેટલો સમય રાખવામાં આવે છે.

સમસ્યા 1: અપલોડ પહેલાં સાઇટ ખાલી થઈ જતી

ફરી પ્રકાશનમાં સાઇટના ફોલ્ડરની બધી ફાઇલો પહેલાં ડિલીટ થતી, અને પછી નવી ફાઇલો અપલોડ થતી. અપલોડ જેટલો સમય ચાલતો — અમારી સ્થાનિક ચકાસણીમાં 250 ફાઇલોની સાઇટ માટે 12 સેકંડ — તે દરમિયાન એજ પર જેની વિનંતી કેશમાં નહોતી તેને 404 મળતું, અથવા એવું HTML પેજ મળતું જેની સ્ક્રિપ્ટ 404 આપતી.

નિષ્ફળ અપલોડ વધુ ખરાબ હતો. ફોલ્ડર પહેલેથી ખાલી હતું, અને બે અપલોડ રસ્તાઓમાંથી એક પર નવો 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 ચિહ્નિત છે. તે નામ હેઠળ ક્યારેય જૂની થઈ શકતી નથી.
• બાકીનું બધું — પેજ અને લોગો જેવી નિશ્ચિત નામવાળી ફાઇલો — no-cache ચિહ્નિત છે, એટલે કે “વાપરતા પહેલાં તપાસો”. કંઈ બદલાયું ન હોય તો જવાબ નાનકડો 304 Not Modified હોય છે, જેમાં બોડી નથી, કારણ કે હવે અમે બ્રાઉઝરના If-None-Match ચેકનો આદર કરીએ છીએ.

આ બંને વચ્ચે ભેદ પાડવામાં કાળજી જોઈએ: public/assets/ ફોલ્ડરમાંથી કૉપી થયેલી ફાઇલ પોતાનું નામ જાળવે છે, અને assets/logo.png ને એક વર્ષ માટે કેશ કરવાથી જૂનો લોગો એક વર્ષ સુધી રહી જાય. તેથી ફાઇલ ત્યારે જ હેશવાળી ગણાય છે જ્યારે તે બિલ્ડ આઉટપુટ ફોલ્ડરમાં હોય અને તેના નામમાં એવો ભાગ હોય જે હેશ જેવો લાગે, સામાન્ય શબ્દ નહીં.

સ્થાનિક રીતે નવું પેજ અને લોગો પ્રકાશન લાઇવ થયાના 6 સેકંડ પછી દેખાયા. પહેલાં પેજ માટે 60 સેકંડ અને લોગો માટે એક દિવસ લાગતો હતો.

અન્ય બે નાના સુધારા

• HEAD વિનંતીમાંથી ખાલી પેજ. HEAD વિનંતી પેજના હેડર બોડી વિના માગે છે. અમે તે ખાલી જવાબો કેશ કરતા હતા, તેથી પછીના મુલાકાતીને તે પેજ ખાલી મળતું. હવે HEAD જવાબો કેશ થતા નથી.
• “અહીં કંઈ નથી” માટે સાચું પેજ. જે સરનામા પર કોઈ એપ નથી ત્યાં પહેલાં 502 એરર કોડ સાથે સાદો ટેક્સ્ટ આવતો: “This published app is offline or the link was not found”. હવે તેને “There's no app here” નામનું યોગ્ય પેજ મળે છે, 404 સ્ટેટસ સાથે, અને માલિક માટે Mythex પર પાછા જવાની લિંક. અજાણ્યા કસ્ટમ ડોમેન પર પણ આ જ પેજ આવે છે.

અમે જે શીખ્યા

• ક્રમ પણ સાચાપણાનો ભાગ છે. એ જ ફાઇલો જુદા ક્રમમાં અપલોડ થાય તો તૂટેલી સાઇટ અને કામ કરતી સાઇટ વચ્ચે ફરક પડે છે.
• મોડું ડિલીટ કરો, અને જે જાણતા હો તે જ. અપલોડ પહેલાં લીધેલી યાદી વડે કાઢવું સલામત છે; અપલોડ પૂરો થશે એવી આશામાં ફોલ્ડર ખાલી કરવું સલામત નથી.
• સમય પર નહીં, વર્ઝન પર કેશ કરો. સમાપ્તિનો સમય એ અનુમાન છે કે સામગ્રી ક્યારે બદલાશે. બિલ્ડ સાથે બદલાતી કી એ હકીકત છે.

સંબંધિત: તમારી પ્રકાશિત એપ ફરી પ્રકાશિત કરતી વખતે પણ ચાલુ રહે છે. પ્રકાશન વિશે વધુ માહિતી માટે docs જુઓ.