Statische sites blijven online terwijl ze opnieuw worden gepubliceerd

Een statische site opnieuw publiceren op Mythex verwijderde vroeger de live bestanden en uploadde daarna pas de nieuwe build. Gedurende de upload kregen sommige bezoekers een 404-pagina of een pagina waarvan de scripts ontbraken. Een mislukte upload kon de site leeg of half nieuw achterlaten. Nu wordt de nieuwe build over de oude geschreven, pagina's als laatste, en worden restanten een paar minuten later verwijderd. Een tweede fix zorgt ervoor dat een nieuwe publicatie binnen seconden zichtbaar is in plaats van binnen een minuut, of, voor bestanden zoals een logo, tot een dag.

Hoe een statische site wordt geserveerd

Een statische site is een site die alleen uit bestanden bestaat: HTML-pagina's, JavaScript, CSS en afbeeldingen. Wanneer je er een publiceert op Mythex, bouwen we hem, uploaden we de uitvoer naar object storage in een map voor jouw site, en serveren we die via een edge-netwerk: servers dichtbij je bezoekers die bestanden uit de opslag halen en er een tijdje kopieën van bewaren. (Als dit nieuw voor je is, legt onze gids over wat een CDN is het idee uit.)

Er was iets mis met twee dingen: de volgorde waarin een nieuwe publicatie de bestanden veranderde, en hoe lang oude kopieën werden bewaard.

Probleem 1: de upload leegde de site eerst

Een nieuwe publicatie verwijderde alles in de map van de site en uploadde daarna de nieuwe build. Zolang de upload duurde (12 seconden voor een site van 250 bestanden in onze lokale test), kreeg een bezoeker wiens verzoek nog niet in de edge-cache zat een 404, of een HTML-pagina waarvan de scripts 404 gaven.

Een mislukte upload was erger. De map was al leeg, en op een van de twee uploadpaden kon de nieuwe index.html terechtkomen vóór het bestand dat faalde. Een publicatie die als mislukt werd gemeld, kon een half nieuwe site live laten.

De oplossing: overschrijven, pagina's als laatste, later opruimen

Verwijder niets vooraf. De nieuwe build wordt over de oude geüpload.
Assets vóór pagina's. Een pagina noemt de scripts en stijlen die ze nodig heeft, dus pagina's worden als laatste geüpload. Totdat de nieuwe pagina's er staan, krijgen bezoekers de oude pagina, die de oude assets noemt, die er nog steeds zijn. Zodra de nieuwe pagina's er zijn, staan de nieuwe assets die ze noemen al op hun plek.
Verwijder restanten later. Vóór de upload leggen we vast waar de site uit bestaat. Drie minuten na een geslaagde upload wordt alles op die lijst dat de nieuwe build niet heeft overschreven, verwijderd. Drie minuten is langer dan de 60 seconden die een pagina aan de edge en in de browser gecachet kan zijn, dus een bezoeker die nog de oude pagina vasthoudt, kan de assets vinden die die pagina noemt.
Bij twijfel verwijder je niets. Als de lijst vóór de upload niet kan worden opgehaald, wordt er niets opgeruimd. Restbestanden zijn onschadelijk, en de volgende publicatie ruimt ze op. Verwijderen zonder te weten wat er stond, is hoe een site leeg eindigt.

Een mislukte upload laat de vorige site nu precies zoals hij was.

We hebben dit end-to-end lokaal getest, met het echte uploadscript, de echte uploadroute en de echte bestandsserving, en met bezoekers die met een koude edge-cache aankwamen. Met de oude code waren 55 van 91 bezoeken kapot tijdens een publicatie en 61 van 92 tijdens een mislukte. Met de nieuwe code waren 0 kapot over ongeveer 3.500 bezoeken, die beide uploadpaden, een mislukte upload en de publicatie daarna omvatten, en werden precies de restbestanden opgeruimd.

Probleem 2: een nieuwe publicatie duurde te lang om zichtbaar te worden

Zelfs wanneer de upload goed verliep, waren wijzigingen traag zichtbaar. De edge bewaarde zijn kopie van een pagina 60 seconden en van elk ander bestand een dag, en vertelde browsers hetzelfde te doen. Bestanden met een vaste naam, zoals logo.png, een font of alles uit een public/-map, konden tot een dag na een nieuwe publicatie de oude versie tonen.

De oplossing: bestandskopieën onder de build

Wanneer de edge onze API vraagt waar een site woont, bevat het antwoord nu een buildmarkering die verandert bij elke publicatie. De edge slaat zijn kopieën onder die markering op. Een publicatie wordt daardoor meteen een volledig nieuwe set cache-sleutels zodra de lookup van de edge van 30 seconden verloopt. Oude kopieën worden simpelweg nooit meer gevonden, dus de edge kan kopieën een dag bewaren zonder ooit één te serveren na de publicatie die hem verving.

Browsers krijgen twee verschillende regels:

Gehashte builduitvoer, bestanden zoals assets/index-CzLcxDO8.js waarvan de naam verandert wanneer de inhoud verandert, wordt een jaar gecachet en als immutable gemarkeerd. Onder die naam kan het nooit verouderd zijn.
Al het andere, pagina's en bestanden met een vaste naam zoals een logo, krijgt no-cache, wat betekent „controleer voor gebruik”. Als er niets veranderde, is het antwoord een kleine 304 Not Modified zonder body, nu we de If-None-Match-controle van de browser honoreren.

Die twee uit elkaar houden vraagt zorg: een bestand gekopieerd uit public/assets/ houdt zijn eigen naam, en assets/logo.png een jaar cachen zou het oude logo een jaar vastzetten. Dus telt een bestand alleen als gehasht als het in een buildmap staat en zijn naam een segment heeft dat op een hash lijkt, niet op een gewoon woord.

Lokaal was de nieuwe pagina en het logo 6 seconden na de live-publicatie zichtbaar. Eerder was dat 60 seconden voor de pagina en een dag voor het logo.

Twee kleinere fixes onderweg

Lege pagina's door HEAD-verzoeken. Een HEAD-verzoek vraagt de headers van een pagina op zonder de body. We cachten die lege antwoorden, waardoor de volgende bezoeker van die pagina een lege pagina kreeg. HEAD-antwoorden worden niet meer gecachet.
Een echte pagina voor „hier is niets”. Een adres zonder app kreeg vroeger een platte tekst „This published app is offline or the link was not found” met een 502-foutcode. Nu krijgt het een goede pagina, „There's no app here”, met een 404-status en een manier terug naar Mythex voor de eigenaar. Onbekende eigen domeinen krijgen dezelfde pagina.

Wat we eruit haalden

Volgorde is onderdeel van correctheid. Dezelfde bestanden in een andere volgorde uploaden is het verschil tussen een kapotte en een werkende site.
Verwijder laat, en alleen wat je kent. Opruimen met een lijst die vóór de upload is genomen, is veilig; een map leegmaken en hopen dat de upload afrondt, is dat niet.
Cache op versie, niet op tijd. Verlooptijden zijn een gok over wanneer inhoud verandert. Een sleutel die met de build verandert, is een feit.

Verwant: je gepubliceerde app blijft online terwijl je hem opnieuw publiceert. Meer over publiceren vind je in de documentatie.