Sajtet statike mbeten online gjatë ripublikimit

Ripublikimi i një sajti statik në Mythex më parë fshinte skedarët live para se të ngarkonte build-in e ri, kështu që për gjatë ngarkimit disa vizitorë merrnin një faqe 404 ose një faqe ku skriptet mungonin. Një ngarkim i dështuar mund ta linte sajtin bosh ose gjysmë të ri. Tani build-i i ri shkruhet mbi të vjetrin, faqet e fundit, dhe mbetjet hiqen disa minuta më vonë. Një rregullim i dytë e bën ripublikimin të shfaqet brenda sekondash, në vend të një minute — ose, për skedarë si një logo, deri në një ditë.

Si shërbehet një sajt statik

Një sajt statik është thjesht skedarë: faqe HTML, JavaScript, CSS, imazhe. Kur e publikoni në Mythex, ne e ndërtojmë, e ngarkojmë daljen në object storage, nën një dosje për sajtin tuaj, dhe e shërbejmë përmes një rrjeti edge — serverë afër vizitorëve tuaj që marrin skedarët nga storage dhe mbajnë kopje për një kohë. (Nëse jeni të rinj me këtë, udhëzuesi ynë për çfarë është një CDN mbulon idenë.)

Dy gjëra ishin gabim: rendi në të cilin një ripublikim ndryshonte skedarët, dhe sa kohë mbaheshin kopjet e vjetra.

Problemi 1: ngarkimi e zbrazte sajtin së pari

Një ripublikim fshinte gjithçka në dosjen e sajtit, pastaj ngarkonte build-in e ri. Për aq kohë sa zgjaste ngarkimi — 12 sekonda për një sajt me 250 skedarë në testin tonë lokal — një vizitor, kërkesa i të cilit nuk ishte tashmë në cache-in e edge-it, merrte një 404, ose një faqe HTML ku skriptet kthenin 404.

Një ngarkim i dështuar ishte më keq. Dosja ishte tashmë bosh, dhe në një nga dy rrugët e ngarkimit index.html i ri mund të vendosej para skedarit që dështoi. Një publikim i raportuar si i dështuar mund ta linte një sajt gjysmë të ri live.

Zgjidhja: shkruaj mbi të vjetrin, faqet në fund, pastro më vonë

Mos fshi së pari. Build-i i ri ngarkohet mbi të vjetrin.
Asetet para faqeve. Një faqe emëron skriptet dhe stilet që i duhen, kështu që faqet ngarkohen të fundit. Derisa të vendosen faqet e reja, vizitorët marrin faqen e vjetër, e cila emëron asetet e vjetra, që janë ende aty. Kur vendosen, asetet e reja që emërojnë janë tashmë në vend.
Hiq mbetjet më vonë. Para ngarkimit, listojmë se nga çfarë përbëhet sajti. Tre minuta pas një ngarkimi të suksesshëm, çdo gjë në atë listë që build-i i ri nuk e rishkroi fshihet. Tre minuta është më shumë se 60 sekondat që një faqe mund të mbahet në cache te edge dhe te shfletuesi, kështu që një vizitor që ende mban faqen e vjetër mund të gjejë asetet që emëron.
Kur ke dyshime, mos fshi asgjë. Nëse lista para ngarkimit dështon, asgjë nuk pastrohet. Skedarët e mbetur janë të padëmshëm, dhe publikimi tjetër i pastron. Fshirja pa e ditur çfarë ishte aty është mënyra se si një sajt mbetet bosh.

Një ngarkim i dështuar tani e lë sajtin e mëparshëm pikërisht ashtu siç ishte.

E testuam nga fillimi në fund lokalisht, duke përdorur skriptin real të ngarkimit, rrugën reale të ngarkimit dhe shërbimin real të storage, me vizitorë që arrinin me cache edge të ftohtë. Me kodin e vjetër, 55 nga 91 vizita u prishën gjatë një ripublikimi dhe 61 nga 92 gjatë një dështimi. Me kodin e ri, 0 u prishën në rreth 3,500 vizita që mbulonin të dyja rrugët e ngarkimit, një dështim dhe publikimin pas tij — dhe u pastruan saktësisht skedarët e mbetur.

Problemi 2: një ripublikim zgjaste të shfaqej

Edhe kur ngarkimi shkonte mirë, ndryshimet vonoheshin të shfaqeshin. Edge-i mbante kopjen e një faqeje për 60 sekonda dhe të çdo skedari tjetër për një ditë, dhe i tregonte shfletuesve ta bëjnë të njëjtën gjë. Skedarët me emër fiks — logo.png, një font, çdo gjë nga një dosje public/ — mund të tregonin versionin e vjetër deri në një ditë pas një ripublikimi.

Zgjidhja: kopje skedarësh nën build-in

Kur edge-i pyet API-n tonë se ku ndodhet një sajt, përgjigjja tani përfshin një shenjues build-i që ndryshon sa herë që vendoset një publikim. Edge-i i ruan kopjet e veta nën atë shenjues. Një publikim bëhet kështu një grup i ri çelësash cache-i sapo skadon kërkimi 30-sekondësh i edge-it. Kopjet e vjetra thjesht nuk gjenden më, kështu që edge-i mund t’i mbajë kopjet për një ditë pa shërbyer kurrë një kopje pas publikimit që e zëvendësoi.

Shfletuesit marrin dy rregulla të ndryshme:

Daljen e build-it me hash — skedarë si assets/index-CzLcxDO8.js, emri i të cilëve ndryshon sa herë ndryshon përmbajtja — ruhet në cache për një vit dhe shënohet si immutable. Nën atë emër nuk mund të jetë kurrë i vjetër.
Çdo gjë tjetër — faqet dhe skedarët me emër fiks si një logo — shënohen no-cache, që do të thotë "kontrollo para përdorimit". Nëse asgjë nuk ka ndryshuar, përgjigjja është një 304 Not Modified shumë i vogël pa trup, tani që respektojmë kontrollin If-None-Match të shfletuesit.

Dallimi kërkon kujdes: një skedar i kopjuar nga public/assets/ mban emrin e vet, dhe ruajtja e assets/logo.png për një vit do të fiksonte logon e vjetër për një vit. Kështu që një skedar konsiderohet me hash vetëm nëse është në një dosje të daljes së build-it dhe emri i tij ka një segment që duket si hash, jo një fjalë e zakonshme.

Lokalisht, faqja dhe logo e reja u panë 6 sekonda pasi publikimi u vendos live. Më parë ishte 60 sekonda për faqen dhe një ditë për logon.

Dy rregullime më të vogla gjatë rrugës

Faqe bosh nga kërkesat HEAD. Një kërkesë HEAD kërkon header-at e një faqeje pa trupin e saj. Ne i ruanim në cache ato përgjigje boshe, kështu që vizitori tjetër i asaj faqeje merrte një faqe të zbrazët. Përgjigjet HEAD nuk ruhen më në cache.
Një faqe reale për "nuk ka asgjë këtu". Një adresë pa aplikacion më parë merrte një tekst të thjeshtë "This published app is offline or the link was not found" me kod 502. Tani merr një faqe të duhur, "There's no app here", me status 404 dhe një rrugë kthimi te Mythex për pronarin. Domenet e personalizuara të panjohura marrin të njëjtën faqe.

Çfarë nxorëm nga kjo

Rendi është pjesë e korrektësisë. Të njëjtët skedarë të ngarkuar në një rend tjetër janë ndryshimi midis një sajti të prishur dhe një sajti që funksionon.
Pastro vonë, dhe vetëm atë që di. Pastrimi me një listë të marrë para ngarkimit është i sigurt; zbrazja e një dosjeje dhe shpresa që ngarkimi të mbarojë nuk është.
Ruaj në cache sipas versionit, jo sipas kohës. Kohët e skadimit janë një supozim për kur ndryshon përmbajtja. Një çelës që ndryshon me build-in është një fakt.

E lidhur: aplikacioni yt i publikuar mbetet online gjatë ripublikimit. Më shumë për publikimin në dokumentacion.