Els llocs estàtics ara segueixen en línia mentre es tornen a publicar

Tornar a publicar un lloc estàtic a Mythex solia esborrar primer els fitxers en viu i després pujar la nova compilació. Durant la pujada, alguns visitants veien una pàgina 404 o una pàgina els scripts de la qual no hi eren. Una pujada fallida podia deixar el lloc buit o mig nou. Ara la nova compilació se sobreescriu sobre l'antiga, primer els recursos i després les pàgines, i els fitxers sobrants s'eliminen uns minuts més tard. Una segona correcció fa que una nova publicació es vegi en segons en lloc d'un minut, o, per a fitxers com un logo, fins a un dia.

Com es serveix un lloc estàtic

Un lloc estàtic és un conjunt de fitxers: pàgines HTML, JavaScript, CSS, imatges. Quan en publiques un a Mythex, el compilem, pugem la sortida a un emmagatzematge d'objectes en una carpeta del teu lloc i el serveix una xarxa d'edge: servidors a prop dels visitants que demanen els fitxers a l'emmagatzematge i en guarden còpies durant una estona. (Si és nou per a tu, la nostra guia sobre què és una CDN explica la idea.)

Hi havia dues coses malament: l'ordre en què una nova publicació canviava els fitxers, i el temps que es mantenien les còpies antigues.

Problema 1: la pujada buidava el lloc primer

Una nova publicació esborrava tot el que hi havia a la carpeta del lloc i després pujava la nova compilació. Mentre durava la pujada (12 segons per a un lloc de 250 fitxers en la nostra prova local), un visitant, la petició del qual no era ja a la memòria cau de l'edge, rebia un 404, o una pàgina HTML els scripts de la qual donaven 404.

Una pujada fallida era pitjor. La carpeta ja estava buida, i en una de les dues rutes de pujada el nou index.html podia arribar abans que el fitxer que fallava. Una publicació informada com a fallida podia deixar en viu un lloc mig nou.

La solució: sobreescriure, pàgines al final, netejar més tard

No esborris primer. La nova compilació es puja per sobre de l'antiga.
Recursos abans que pàgines. Una pàgina indica els scripts i estils que necessita, així que les pàgines pugen les últimes. Fins que arriben les noves pàgines, el visitant rep la pàgina antiga, que indica els recursos antics, que encara hi són. Quan arriben, els nous recursos que indiquen ja són al seu lloc.
Elimina els sobrants més tard. Abans de la pujada, fem una llista del que forma el lloc. Tres minuts després d'una pujada correcta, s'esborra tot allò de la llista que la nova compilació no ha reescrit. Tres minuts són més que els 60 segons que una pàgina pot estar en memòria cau a l'edge i al navegador, de manera que un visitant que encara té la pàgina antiga pot trobar els recursos que aquesta indica.
Si tens dubtes, no n'esborris cap. Si el llistat previ a la pujada falla, no s'esborra res. Els fitxers sobrants no fan mal, i la següent publicació els neteja. Esborrar sense saber què hi havia és la manera com un lloc acaba buit.

Una pujada fallida ara deixa el lloc anterior exactament com estava.

Ho vam provar de cap a cap en local, amb l'script de pujada real, la ruta de pujada real i el servei de l'emmagatzematge, i amb visitants que arribaven amb una memòria cau d'edge freda. Amb el codi antic, 55 de 91 visites van fallar durant una publicació, i 61 de 92 durant una fallida. Amb el codi nou, 0 van fallar en unes 3.500 visites que cobrien les dues rutes de pujada, una pujada fallida i la publicació posterior, i exactament els fitxers sobrants es van eliminar.

Problema 2: una publicació trigava massa a veure's

Fins i tot quan la pujada anava bé, els canvis trigaven a aparèixer. L'edge guardava la seva còpia d'una pàgina durant 60 segons i la de la resta de fitxers durant un dia, i indicava als navegadors que fessin el mateix. Els fitxers amb nom fix, com logo.png, una font o qualsevol cosa de la carpeta public/, podien mostrar la versió antiga fins a un dia després d'una publicació.

La solució: còpies de fitxers sota la compilació

Quan l'edge pregunta a la nostra API on viu un lloc, la resposta ara inclou un marcador de compilació que canvia cada vegada que arriba una publicació. L'edge guarda les seves còpies sota aquest marcador. Una publicació es converteix, per tant, en un conjunt nou de claus de memòria cau tan bon punt caduca la consulta de 30 segons de l'edge. Les còpies antigues simplement ja no es troben mai més, de manera que l'edge pot conservar còpies durant un dia sense servir-ne mai una més enllà de la publicació que la va substituir.

Els navegadors reben dues regles diferents:

La sortida de compilació amb hash, fitxers com assets/index-CzLcxDO8.js, el nom dels quals canvia quan canvia el contingut, es guarda durant un any i es marca com a immutable. Sota aquest nom mai no pot quedar desfasat.
Tota la resta, és a dir, pàgines i fitxers de nom fix com un logo, es marca com a no-cache, que vol dir «comprova abans d'usar». Si no ha canviat res, la resposta és un petit 304 Not Modified sense cos, ara que respectem la comprovació If-None-Match del navegador.

Distingir els dos casos requereix cura: un fitxer copiat de public/assets/ conserva el seu nom, i guardar assets/logo.png durant un any fixaria el logo antic durant un any. Per això, un fitxer només compta com a amb hash si és en una carpeta de sortida de compilació i el seu nom té un segment que sembla un hash, no una paraula corrent.

En local, la nova pàgina i el logo es van veure 6 segons després que la publicació fos en viu. Abans eren 60 segons per a la pàgina i un dia per al logo.

Dues correccions més petites pel camí

Pàgines en blanc amb peticions HEAD. Una petició HEAD demana les capçaleres d'una pàgina sense el cos. Estàvem guardant aquestes respostes buides, i el visitant següent a aquella pàgina veia una pàgina en blanc. Les respostes HEAD ja no es guarden a la memòria cau.
Una pàgina real per a «aquí no hi ha res». Una adreça sense aplicació rebia un text pla «Aquesta aplicació publicada està fora de servei o l'enllaç no s'ha trobat» amb un codi d'error 502. Ara rep una pàgina adequada, «Aquí no hi ha cap aplicació», amb estat 404 i un camí de tornada a Mythex per al propietari. Els dominis personalitzats desconeguts reben la mateixa pàgina.

Què ens hem endut

L'ordre també forma part de la correcció. Els mateixos fitxers pujats en un ordre diferent són la diferència entre un lloc trencat i un lloc que funciona.
Esborra tard, i només el que coneixes. Netejar amb un llistat pres abans de la pujada és segur; buidar una carpeta i esperar que la pujada acabi no ho és.
Fes memòria cau per versió, no per temps. Els temps de caducitat són una suposició sobre quan canvia el contingut. Una clau que canvia amb la compilació és un fet.

Relacionat: la teva aplicació publicada ara segueix en línia mentre la tornes a publicar. Més sobre publicació als documents.