Statiska webbplatser förblir uppe under ompublicering

Att publicera om en statisk webbplats på Mythex brukade ta bort de publicerade filerna först och sedan ladda upp det nya bygget. Under uppladdningen fick därför vissa besökare en 404-sida eller en sida där skripten saknades. En misslyckad uppladdning kunde lämna sajten tom eller halvt ny. Nu skrivs det nya bygget över det gamla, med sidorna sist, och det som blivit över tas bort några minuter senare. En andra rättelse gör att en ny publicering syns på sekunder i stället för en minut — eller, för filer som en logotyp, upp till ett dygn.

Så serveras en statisk webbplats

En statisk webbplats består bara av filer: HTML-sidor, JavaScript, CSS och bilder. När du publicerar en sådan på Mythex bygger vi den, laddar upp resultatet till objektlagring i en mapp för din webbplats och serverar den via ett edge-nätverk. Det är servrar nära dina besökare som hämtar filer från lagringen och sparar kopior en stund. (Om du är ny på området förklarar vår guide om vad ett CDN är idén.)

Två saker var fel: i vilken ordning en ompublicering ändrade filerna, och hur länge gamla kopior sparades.

Problem 1: uppladdningen tömde sajten först

En ompublicering raderade allt i webbplatsens mapp och laddade sedan upp det nya bygget. Så länge uppladdningen tog — 12 sekunder för en sajt med 250 filer i vårt lokala test — fick en besökare vars begäran inte redan låg i edge-cachen en 404-sida, eller en HTML-sida vars skript gav 404.

En misslyckad uppladdning var värre. Mappen var redan tom, och på en av de två uppladdningsvägarna kunde den nya index.html landa innan filen som misslyckades. En publicering som rapporterades som misslyckad kunde alltså lämna en halvt ny sajt live.

Lösningen: skriv över, sidorna sist, rensa senare

1. Ta inte bort först. Det nya bygget laddas upp ovanpå det gamla.
2. Tillgångar före sidor. En sida anger vilka skript och stilmallar den behöver, så sidorna laddas upp sist. Tills de nya sidorna landat får besökarna den gamla sidan, som pekar på de gamla tillgångarna, och de finns fortfarande kvar. När de nya sidorna väl landat finns de nya tillgångarna de pekar på redan på plats.
3. Ta bort rester senare. Före uppladdningen listar vi vad webbplatsen består av. Tre minuter efter en lyckad uppladdning tas allt i listan som det nya bygget inte skrev över bort. Tre minuter är längre än de 60 sekunder en sida kan ligga i cachen vid edge och i webbläsaren, så en besökare som fortfarande har den gamla sidan kan hitta de tillgångar den pekar på.
4. Vid tvekan, ta bort ingenting. Om listningen före uppladdningen misslyckas tas inget bort. Filer som blivit kvar är ofarliga, och nästa publicering rensar dem. Att ta bort utan att veta vad som fanns där är så en sajt blir tom.

En misslyckad uppladdning lämnar nu den tidigare webbplatsen exakt som den var.

Vi testade detta från början till slut lokalt, med det riktiga uppladdningsskriptet, den riktiga uppladdningsrutten och riktig filservering, och med besökare som kom in med en kall edge-cache. Med den gamla koden var 55 av 91 besök trasiga under en ompublicering och 61 av 92 under en misslyckad. Med den nya koden var 0 trasiga över cirka 3 500 besök. Testet omfattade båda uppladdningsvägarna, en misslyckad uppladdning och publiceringen efter den. Exakt de kvarvarande filerna rensades.

Problem 2: en ompublicering tog för lång tid att synas

Även när uppladdningen gick bra var ändringarna långsamma att synas. Edge höll en kopia av en sida i 60 sekunder och av alla andra filer i ett dygn, och bad webbläsarna göra detsamma. Filer med fast namn — logo.png, ett typsnitt, allt från en mapp public/ — kunde visa den gamla versionen i upp till ett dygn efter en ompublicering.

Lösningen: filkopior under bygget

När edge frågar vårt API var en webbplats finns, innehåller svaret nu en byggmarkör som ändras varje gång en publicering går igenom. Edge lagrar sina kopior under den markören. En publicering blir därför en helt ny uppsättning cache-nycklar så snart edges uppslagning på 30 sekunder har gått ut. Gamla kopior hittas aldrig igen, så edge kan behålla kopior i ett dygn utan att någonsin servera en som ersatts av en senare publicering.

Webbläsarna får två olika regler:

• Hashat bygg-output, som filer med namn som assets/index-CzLcxDO8.js och som ändrar namn när innehållet ändras, cachas i ett år och markeras som immutable. Under det namnet kan de aldrig vara inaktuella.
• Allt annat, det vill säga sidor och filer med fast namn som en logotyp, markeras med no-cache, vilket betyder ”kontrollera innan du använder”. Om inget har ändrats är svaret ett litet 304 Not Modified utan innehåll, eftersom vi nu respekterar webbläsarens If-None-Match-kontroll.

Att skilja dem åt kräver omsorg. En fil som kopierats från public/assets/ behåller sitt eget namn, och om assets/logo.png cachades i ett år skulle den gamla logotypen låsas fast i ett år. En fil räknas därför bara som hashad om den ligger i en bygg-output-mapp och dess namn har ett segment som ser ut som en hash, inte ett vanligt ord.

Lokalt syntes den nya sidan och logotypen 6 sekunder efter att publiceringen gick live. Tidigare tog det 60 sekunder för sidan och ett dygn för logotypen.

Två mindre rättelser på vägen

• Tomma sidor från HEAD-begäranden. En HEAD-begäran frågar efter en sidas headers utan innehållet. Vi cachade de tomma svaren, så nästa besökare av sidan fick en tom sida. HEAD-svar cachas inte längre.
• En riktig sida för ”det finns inget här”. En adress utan app fick tidigare en vanlig textsida med meddelandet “This published app is offline or the link was not found” och statuskoden 502. Nu får den en ordentlig sida, “There's no app here”, med statuskoden 404 och en väg tillbaka till Mythex för ägaren. Okända egna domäner får samma sida.

Det vi tog med oss

• Ordningen är en del av korrektheten. Samma filer uppladdade i en annan ordning är skillnaden mellan en trasig och en fungerande sajt.
• Ta bort sent, och bara det du vet. Rensning med en lista tagen före uppladdningen är säker. Att tömma en mapp och hoppas att uppladdningen blir klar är det inte.
• Cacha efter version, inte efter tid. Utgångstider är en gissning om när innehållet ändras. En nyckel som ändras med bygget är ett faktum.

Relaterat: din publicerade app förblir uppe medan du publicerar om den. Mer om publicering finns i dokumentationen.