A statikus oldalak újrapublikálás közben is elérhetők maradnak

A statikus oldal Mythexen történő újrapublikálása korábban előbb törölte az élő fájlokat, és csak utána töltötte fel az új buildet. A feltöltés ideje alatt néhány látogató 404-es oldalt, vagy olyan oldalt kapott, amelyből hiányoztak a szkriptek. Egy sikertelen feltöltés az oldalt üresen vagy félig újan hagyhatta. Most az új buildet a régi fölé írjuk, az oldalakat utoljára, a maradékokat pedig néhány perccel később töröljük. Egy második javítás miatt az újrapublikálás másodpercek alatt látszik, nem egy perc alatt — vagy olyan fájloknál, mint egy logó, legfeljebb egy nap alatt.

Hogyan szolgálunk ki egy statikus oldalt

A statikus oldal olyan oldal, amely csak fájlokból áll: HTML-oldalak, JavaScript, CSS, képek. Mythexen a publikálásnál felépítjük, a kimenetet egy objektumtárolóba töltjük fel az oldalad mappája alá, és egy edge-hálózaton keresztül szolgáljuk ki — szervereken, amelyek a látogatóidhoz közel vannak, a fájlokat a tárolóból húzzák, és egy ideig megtartják a másolataikat. (Ha ez új számodra, a mi a CDN útmutatónk elmagyarázza az ötletet.)

Két dolog volt hibás: a változtatások sorrendje újrapublikáláskor, és az, hogy meddig tartották meg a régi másolatokat.

1. probléma: a feltöltés előbb kiürítette az oldalt

Az újrapublikálás törölte az oldal mappájának teljes tartalmát, majd feltöltötte az új buildet. Amíg a feltöltés tartott — a helyi tesztünkben egy 250 fájlos oldalnál 12 másodperc —, egy olyan látogató, akinek a kérése nem volt már gyorsítótárazva az edge-en, 404-et kapott, vagy egy HTML-oldalt, amelynek szkriptjei 404-et adtak.

A sikertelen feltöltés rosszabb volt. A mappa már üres volt, és az egyik feltöltési útvonalon az új index.html landolhatott azelőtt, hogy a sikertelen fájl feltöltődött volna. A sikertelennek jelentett publikálás félig új oldalt hagyhatott élesben.

A megoldás: felülírás, oldalak utoljára, takarítás később

1. Ne törölj először. Az új buildet a régi fölé töltjük fel.
2. Eszközök az oldalak előtt. Az oldal megnevezi a szkripteket és stílusokat, amelyekre szüksége van, ezért az oldalak utoljára kerülnek fel. Amíg az új oldalak fel nem kerülnek, a látogató a régi oldalt kapja, amely a régi eszközöket nevezi meg, és ezek még ott vannak. Amint feltöltődnek, az általuk megnevezett új eszközök már a helyükön vannak.
3. A maradékokat később töröljük. A feltöltés előtt listázzuk, miből áll az oldal. Egy sikeres feltöltés után három perccel minden olyan elem törlődik ebből a listából, amelyet az új build nem írt felül. Három perc hosszabb, mint az a 60 másodperc, amennyit egy oldal az edge-en és a böngészőben gyorsítótárazva lehet, így a régi oldalt még birtokló látogató is megtalálja a benne nevezett eszközöket.
4. Kétség esetén ne törölj semmit. Ha a feltöltés előtti listázás meghiúsul, semmi nem törlődik. A maradék fájlok ártalmatlanok, a következő publikálás pedig eltakarítja őket. Törlés anélkül, hogy tudnánk, mi volt ott, az a módja, ahogy egy oldal üresen végzi.

Egy sikertelen feltöltés most pontosan úgy hagyja hátra az előző oldalt, ahogy volt.

Végponttól végpontig teszteltük helyben, az éles feltöltő szkripttel, az éles feltöltési útvonallal és a tároló kiszolgálásával, hidegen induló edge-gyorsítótárral érkező látogatókkal. A régi kóddal 55 a 91 látogatásból hibás volt egy újrapublikálás közben, és 61 a 92-ből egy sikertelen közben. Az új kóddal 0 volt hibás a mintegy 3500 látogatásból, amely mindkét feltöltési útvonalat, egy sikertelen feltöltést és az utána következő publikálást lefedte — és pontosan a maradék fájlok törlődtek.

2. probléma: az újrapublikálás túl sokáig tartott, mire látszott

Ezt akkor is láttuk, ha a feltöltés rendben ment: a változások lassan jelentek meg. Az edge 60 másodpercig őrizte az oldal másolatát, minden más fájlét pedig egy napig, és ezt a böngészőknek is megmondta. A fix nevű fájlok — logo.png, egy betűtípus, bármi a public/ mappából — az újrapublikálás után akár egy napig a régi verziót mutathatták.

A megoldás: fájlmásolatok a build alatt

Amikor az edge megkérdezi az API-tól, hol van egy oldal, a válasz most tartalmaz egy build-jelölőt, amely minden sikeres publikálásnál megváltozik. Az edge a másolatait ez alá a jelölő alá rendezi. Egy publikálás így azonnal új gyorsítótár-kulcsok sorozatává válik, amint az edge 30 másodperces keresése lejár. A régi másolatokat egyszerűen soha nem találja meg, így az edge egy napig megtarthat másolatokat úgy, hogy soha nem szolgál ki olyat, amelyet a publikálás már felülírt.

A böngészők két különböző szabályt kapnak:

• Hash-elt build-kimenet — olyan fájlok, mint az assets/index-CzLcxDO8.js, amelyek neve megváltozik, amikor a tartalom is — egy évig gyorsítótárazható, és immutable-nek jelölt. Ezen a néven soha nem lehet elavult.
• Minden más — oldalak és fix nevű fájlok, mint egy logó — no-cache jelölést kapnak, ami azt jelenti, „ellenőrizd használat előtt”. Ha nem változott semmi, a válasz egy apró 304 Not Modified, törzs nélkül, mert most már tiszteletben tartjuk a böngésző If-None-Match ellenőrzését.

A kettő megkülönböztetése gondosságot igényel: a public/assets/ mappából másolt fájl megtartja a nevét, és az assets/logo.png egy évre való gyorsítótárazása a régi logót egy évig rögzítené. Ezért egy fájl csak akkor számít hash-elt fájlnak, ha egy build-kimeneti mappában van, és a nevében van egy hashre emlékeztető szegmens, nem egy hétköznapi szó.

Helyben az új oldal és logó 6 másodperccel a publikálás élesedése után látszott. Korábban az oldalnál 60 másodperc, a logónál egy nap volt.

Két kisebb javítás az út során

• Üres oldalak a HEAD-kérésekből. A HEAD kérés csak a fejléceket kéri egy oldalról, a törzset nem. Ezeket az üres válaszokat gyorsítótáraztuk, így a következő látogató az oldalt üresen kapta. A HEAD-válaszok már nem kerülnek gyorsítótárba.
• Valódi oldal arra, ami nincs. Egy címre, ahol nincs app, korábban egy egyszerű szöveges „This published app is offline or the link was not found” üzenet ment 502-es hibakóddal. Most egy megfelelő oldal jelenik meg, „Itt nincs app” felirattal, 404-es státusszal és visszalinkkel a Mythexre a tulajdonosnak. Az ismeretlen egyedi domainek ugyanezt az oldalt kapják.

Amit ebből tanultunk

• A sorrend is a helyesség része. Ugyanazok a fájlok más sorrendben feltöltve a különbség egy törött és egy működő oldal között.
• Későn törölj, és csak azt, amit ismersz. A feltöltés előtti listázással végzett törlés biztonságos; egy mappa kiürítése abban a reményben, hogy a feltöltés befejeződik, nem az.
• Verzió szerint gyorsítótárazz, ne idő szerint. A lejárati idők találgatások arról, mikor változik a tartalom. A buildtől függő kulcs tény.

Kapcsolódó: a publikált appod az újrapublikálás alatt is elérhető marad. A publikálásról további részletek a dokumentációban.