Statické weby zůstávají online, i když se znovu publikují

Opětovné publikování statického webu na Mythexu dřív smazalo živé soubory a teprve potom nahrálo nový build. Po dobu nahrávání tak některí návštěvníci dostali stránku 404 nebo stránku, jejíž skripty chyběly. Neúspěšné nahrání mohlo web nechat prázdný nebo napůl nový. Nyní se nový build zapisuje přes starý, stránky nakonec, a zbytky se odstraní o několik minut později. Druhá oprava zajistí, že se opětovné publikování projeví do několika sekund místo jedné minuty – nebo, u souborů jako logo, až za jeden den.

Jak se statický web servíruje

Statický web je jen soubory: HTML stránky, JavaScript, CSS, obrázky. Když ho publikujete na Mythexu, sestavíme ho, nahrajeme výstup do objektového úložiště do složky pro váš web a servírujeme ho přes edge síť – servery blízko návštěvníků, které načítají soubory z úložiště a nějakou dobu si drží jejich kopie. (Pokud je to pro vás nové, náš průvodce co je CDN vysvětluje tuto myšlenku.)

Šlo o dvě věci: pořadí, v jakém opětovné publikování měnilo soubory, a jak dlouho se uchovávaly staré kopie.

Problém 1: nahrávání nejdřív vyprázdnilo web

Opětovné publikování smazalo vše ve složce webu a teprve potom nahrálo nový build. Po dobu nahrávání – 12 sekund pro web se 250 soubory v našem lokálním testu – dostal návštěvník, jehož požadavek nebyl už uložený na edge, chybu 404, nebo HTML stránku, jejíž skripty vracely 404.

Neúspěšné nahrání bylo horší. Složka už byla prázdná a na jedné z obou cest nahrávání se mohl nový index.html objevit dřív, než selhal soubor, který mělo následovat. Publikování hlášené jako neúspěšné mohlo nechat napůl nový web živý.

Oprava: zapisovat přes, stránky nakonec, mazat později

Nemazat nejdřív. Nový build se nahraje přes starý.
Assety před stránkami. Stránka jmenuje skripty a styly, které potřebuje, takže stránky jdou nahoru jako poslední. Dokud nové stránky nedorazí, návštěvník dostane starou stránku, která jmenuje staré assety, a ty tam ještě jsou. Jakmile nové stránky dorazí, nové assety, na které odkazují, už jsou na místě.
Zbytky odstranit později. Před nahráním zjistíme, z čeho se web skládá. Tři minuty po úspěšném nahrání se smaže cokoli z tohoto seznamu, co nový build nepřepsal. Tři minuty jsou déle než 60 sekund, po které může být stránka uložená na edge a v prohlížeči, takže návštěvník, který stále drží starou stránku, najde assety, které pojmenovává.
Při pochybnostech nemazat nic. Pokud výpis před nahráním selže, nic se nemaže. Zbylé soubory nejsou škodlivé a další publikování je vyčistí. Mazání bez znalosti toho, co tam bylo, je způsob, jak web skončí prázdný.

Neúspěšné nahrání nyní nechá předchozí web přesně tak, jak byl.

Testovali jsme to celé lokálně, se skutečným skriptem nahrávání, skutečnou trasou nahrávání a servírováním úložiště, a s návštěvníky přicházejícími s chladnou cache edge. Se starým kódem bylo 55 z 91 návštěv během opětovného publikování rozbitých a 61 z 92 při neúspěšném. S novým kódem bylo rozbitých 0 z přibližně 3 500 návštěv pokrývajících obě cesty nahrávání, neúspěšné nahrání a publikování po něm – a odstraněny byly přesně zbylé soubory.

Problém 2: opětovné publikování se projevovalo příliš dlouho

I když nahrávání proběhlo v pořádku, změny se objevovaly pomalu. Edge držel kopii stránky 60 sekund a kopii každého dalšího souboru jeden den a totéž nařizoval prohlížečům. Soubory s pevným názvem – logo.png, font, cokoli ze složky public/ – mohly zobrazovat starou verzi až jeden den po opětovném publikování.

Oprava: kopie souborů pod označením buildu

Když se edge zeptá našeho API, kde web žije, odpověď nyní obsahuje značku buildu, která se změní pokaždé, když publikování projde. Edge ukládá své kopie pod touto značkou. Publikování se tak stane zcela novou sadou klíčů cache, jakmile vyprší 30sekundové vyhledání na edge. Staré kopie se už nikdy nenajdou, takže edge může kopie držet jeden den, aniž by kdy servíroval kopii starší, než publikování, které ji nahradilo.

Prohlížeče dostávají dvě různá pravidla:

Hashované výstupy buildu – soubory jako assets/index-CzLcxDO8.js, jejichž název se změní, kdykoli se změní obsah – se cachují na rok a označují jako immutable. Pod tímto názvem nemohou nikdy zastarat.
Vše ostatní – stránky a soubory s pevným názvem jako logo – je označeno no-cache, což znamená „ověř před použitím“. Pokud se nic nezměnilo, přijde drobná odpověď 304 Not Modified bez těla, nyní, když respektujeme kontrolu If-None-Match z prohlížeče.

Rozlišit ta dvě musíte opatrně: soubor zkopírovaný z public/assets/ si zachová svůj název a cachování assets/logo.png na rok by na rok přišpendlilo starý logo. Soubor proto počítáme jako hashovaný jen tehdy, je-li ve složce výstupu buildu a jeho název obsahuje segment vypadající jako hash, ne běžné slovo.

Lokálně byly nová stránka a logo viditelné 6 sekund po tom, co se publikování projevilo. Předtím to bylo 60 sekund pro stránku a jeden den pro logo.

Dvě menší opravy po cestě

Prázdné stránky z požadavků HEAD. Požadavek HEAD žádá hlavičky stránky bez jejího těla. Cachovali jsme ty prázdné odpovědi, takže další návštěvník této stránky dostal prázdnou stránku. Odpovědi HEAD se už necachují.
Skutečná stránka pro „tady nic není“. Adresa bez aplikace dřív vrátila prostý text „Tato publikovaná aplikace je offline nebo odkaz nebyl nalezen“ s chybovým kódem 502. Nyní dostane pořádnou stránku „Tady není žádná aplikace“ se stavem 404 a odkazem zpět na Mythex pro vlastníka. Neznámé vlastní domény dostanou tutéž stránku.

Co jsme si z toho odnesli

Pořadí je součástí správnosti. Stejné soubory nahrané v jiném pořadí jsou rozdílem mezi rozbitým a fungujícím webem.
Mažte pozdě a jen to, co znáte. Mazání podle výpisu pořízeného před nahráním je bezpečné; vyprázdnit složku a doufat, že nahrávání doběhne, bezpečné není.
Cachujte podle verze, ne podle času. Doby expirace jsou odhad, kdy se obsah změní. Klíč, který se mění s buildem, je fakt.

Související: váš publikovaný web zůstává online i během opětovného publikování. Více o publikování v dokumentaci.