Statiske nettsteder forblir oppe under republisering

Å republisere et statisk nettsted på Mythex slettet tidligere de live filene før den nye byggingen ble lastet opp. I den tiden opplastingen tok, fikk noen besøkende en 404-side, eller en side der skriptene manglet. En mislykket opplasting kunne etterlate nettstedet tomt eller halvveis nytt. Nå skrives den nye byggingen over den gamle, med sidene sist, og rester fjernes noen minutter senere. En andre rettelse gjør at en republisering vises innen sekunder i stedet for ett minutt — eller, for filer som en logo, opptil en dag.

Slik serveres et statisk nettsted

Et statisk nettsted består bare av filer: HTML-sider, JavaScript, CSS og bilder. Når du publiserer et slikt nettsted på Mythex, bygger vi det, laster resultatet opp til objektlagring i en mappe for nettstedet ditt, og serverer det gjennom et edge-nettverk: servere nær besøkende som henter filer fra lagringen og beholder kopier av dem en stund. (Er du ny til dette, forklarer guiden vår om hva et CDN er ideen.)

To ting var galt: rekkefølgen filene ble endret i under en republisering, og hvor lenge gamle kopier ble beholdt.

Problem 1: opplastingen tømte nettstedet først

En republisering slettet alt i nettstedets mappe og lastet deretter opp den nye byggingen. Så lenge opplastingen varte — 12 sekunder for et nettsted med 250 filer i vår lokale test — fikk en besøkende hvis forespørsel ikke allerede lå i cache på edge, en 404, eller en HTML-side der skriptene ga 404.

En mislykket opplasting var verre. Mappen var allerede tom, og på en av de to opplastingsveiene kunne den nye index.html havne før filen som feilet. En publisering som ble rapportert som mislykket, kunne etterlate et halvveis nytt nettsted live.

Løsningen: skriv over, sider sist, rydd senere

Ikke slett først. Den nye byggingen lastes opp oppå den gamle.
Ressurser før sider. En side nevner skriptene og stilene den trenger, så sidene lastes opp sist. Helt til de nye sidene er på plass, får besøkende den gamle siden, som nevner de gamle ressursene, og de finnes fortsatt. Når de nye sidene lander, ligger ressursene de nevner allerede der.
Fjern rester senere. Før opplastingen lister vi opp hva nettstedet består av. Tre minutter etter en vellykket opplasting slettes alt på listen som den nye byggingen ikke skrev over. Tre minutter er lengre enn de 60 sekundene en side kan ligge i cache på edge og i nettleseren, så en besøkende som fortsatt har den gamle siden, finner ressursene den nevner.
Er du i tvil, slett ingenting. Hvis listingen før opplastingen mislykkes, fjernes ingenting. Restfiler er ufarlige, og neste publisering rydder dem bort. Å slette uten å vite hva som fantes, er slik et nettsted ender tomt.

En mislykket opplasting etterlater nå det forrige nettstedet akkurat slik det var.

Vi testet dette fra ende til ende lokalt, med det faktiske opplastingsskriptet, den faktiske opplastingsruten og lagringsservering, og med besøkende som kom med en kald edge-cache. Med den gamle koden var 55 av 91 besøk ødelagt under en republisering og 61 av 92 under en mislykket. Med den nye koden var 0 ødelagt på rundt 3 500 besøk, som dekket begge opplastingsveiene, en mislykket opplasting og publiseringen etter den — og nøyaktig restfilene ble fjernet.

Problem 2: en republisering tok for lang tid å vise seg

Selv når opplastingen gikk bra, var endringer trege å dukke opp. Edge beholdt kopien av en side i 60 sekunder og av alle andre filer i en dag, og ba nettlesere gjøre det samme. Filer med fast navn — logo.png, en font, alt fra en public/-mappe — kunne vise den gamle versjonen i opptil en dag etter en republisering.

Løsningen: filkopier under byggingen

Når edge spør API-et vårt hvor et nettsted ligger, inkluderer svaret nå en byggemarkør som endres hver gang en publisering går gjennom. Edge lagrer kopiene sine under den markøren. En publisering blir dermed et helt nytt sett med cache-nøkler så snart edge sitt 30-sekunders oppslag utløper. Gamle kopier blir ganske enkelt aldri funnet igjen, så edge kan beholde kopier i en dag uten å servere en som er eldre enn publiseringen som erstattet den.

Nettlesere får to ulike regler:

Hashet byggeutdata — filer som assets/index-CzLcxDO8.js, der navnet endres når innholdet gjør det — caches i ett år og merkes som immutable. Under det navnet kan de aldri være utdaterte.
Alt annet — sider og filer med fast navn, som en logo — merkes no-cache, altså «sjekk før bruk». Hvis ingenting har endret seg, er svaret en liten 304 Not Modified uten innhold, nå som vi respekterer nettleserens If-None-Match-sjekk.

Å skille dem fra hverandre krever omtanke: en fil kopiert fra public/assets/ beholder sitt eget navn, og å cache assets/logo.png i ett år ville låst den gamle logoen i et år. En fil regnes derfor bare som hashet hvis den ligger i en byggeutdatamappe og navnet har et segment som ser ut som en hash, ikke et vanlig ord.

Lokalt var den nye siden og logoen synlige 6 sekunder etter at publiseringen gikk live. Før var det 60 sekunder for siden og en dag for logoen.

To mindre rettelser underveis

Tomme sider fra HEAD-forespørsler. En HEAD-forespørsel ber om en sides headere uten innholdet. Vi cachet de tomme svarene, så neste besøkende til siden fikk en tom side. HEAD-svar caches ikke lenger.
En ekte side for «ingenting her». En adresse uten app fikk tidligere en ren tekstmelding, «This published app is offline or the link was not found», med feilkode 502. Nå får den en skikkelig side, «There's no app here», med status 404 og en vei tilbake til Mythex for eieren. Ukjente egne domener får samme side.

Det vi lærte

Rekkefølge er en del av korrekthet. De samme filene lastet opp i en annen rekkefølge er forskjellen mellom et ødelagt og et fungerende nettsted.
Slett sent, og bare det du vet om. Å rydde med en liste tatt før opplastingen er trygt. Å tømme en mappe og håpe at opplastingen blir ferdig, er ikke trygt.
Cache etter versjon, ikke etter tid. Utløpstider er en gjetning om når innhold endres. En nøkkel som endres med byggingen, er et faktum.

Relatert: publiseringen av appen din forblir oppe mens du republiserer den. Mer om publisering finner du i dokumentasjonen.