Nananatiling Live ang Static Sites Habang Nire-republish

Dati, binubura muna ng pag-republish ng static site sa Mythex ang mga live na file bago i-upload ang bagong build, kaya sa tagal ng upload, may ilang bisitang nakakakuha ng 404 page o page na nawawala ang mga script. Maaaring mag-iwan ang pumalpak na upload ng site na walang laman o kalahating bago. Ngayon, isinusulat na ang bagong build sa ibabaw ng luma, ang mga page ang huli, at tinatanggal ang mga natitira pagkalipas ng ilang minuto. Isa pang ayos ang nagpapalabas ng republish sa loob ng ilang segundo sa halip na isang minuto, o, para sa mga file gaya ng logo, hanggang isang araw.

Paano sine-serve ang static site

Ang static site ay mga file lang: HTML pages, JavaScript, CSS, mga larawan. Kapag nag-publish ka nito sa Mythex, ibinubuild namin ito, ina-upload ang output sa object storage sa ilalim ng folder para sa site mo, at sine-serve ito sa pamamagitan ng edge network, mga server na malapit sa mga bisita mo na kumukuha ng file mula sa storage at nagtatago ng kopya nito sa loob ng ilang panahon. (Kung bago ka rito, sakop ng aming gabay tungkol sa ano ang CDN ang ideya.)

May dalawang bagay na mali: ang pagkakasunod-sunod kung paano binabago ng republish ang mga file, at kung gaano katagal itinatago ang mga lumang kopya.

Problema 1: inubos muna ng upload ang site

Binubura ng republish ang lahat sa folder ng site, pagkatapos ina-upload ang bagong build. Sa tagal ng upload, 12 segundo para sa 250-file na site sa aming lokal na test, ang bisitang ang request ay hindi pa naka-cache sa edge ay nakakakuha ng 404, o HTML page na ang mga script ay nagbabalik ng 404.

Mas malala ang pumalpak na upload. Walang laman na ang folder, at sa isa sa dalawang upload path, maaaring mapunta ang bagong index.html bago ang file na pumalpak. Ang publish na iniulat na pumalpak ay maaaring mag-iwan ng kalahating bagong site na live.

Ang ayos: isulat sa ibabaw, pages sa huli, linisin pagkatapos

Huwag munang burahin. Ina-upload ang bagong build sa ibabaw ng luma.
Assets bago ang pages. Pinangalanan ng page ang mga script at style na kailangan nito, kaya ang pages ang huling ina-upload. Hanggang sa dumating ang bagong pages, makikita ng mga bisita ang lumang page, na nagpapangalan ng lumang assets, at nandoon pa rin ang mga iyon. Kapag dumating na ang bagong pages, nasa lugar na ang bagong assets na pinangalanan nila.
Tanggalin ang natitira pagkatapos. Bago ang upload, inililista namin kung ano ang bumubuo sa site. Tatlong minuto pagkatapos ng matagumpay na upload, binubura ang anumang nasa listahang iyon na hindi isinulat ulit ng bagong build. Mas mahaba ang tatlong minuto kaysa sa 60 segundo na maaaring i-cache ng page sa edge at sa browser, kaya ang bisitang may hawak pa ring lumang page ay makakahanap pa rin ng assets na pinangalanan nito.
Kapag may pagdududa, huwag magbura ng kahit ano. Kapag pumalpak ang listahan bago ang upload, walang papalisin. Hindi nakakasama ang natitirang file, at lilinisin ito ng susunod na publish. Ang pagbura nang hindi alam kung ano ang naroon ang paraan para mawalan ng laman ang site.

Ngayon, ang pumalpak na upload ay iniiwan ang nakaraang site nang eksakto kung paano ito dati.

Sinubukan namin ito nang buo sa lokal, gamit ang totoong upload script, ang totoong upload route at storage serving, at mga bisitang dumarating nang may malamig na edge cache. Sa lumang code, 55 sa 91 na bisita ang nasira habang nagre-republish, at 61 sa 92 habang pumapalya ang republish. Sa bagong code, 0 ang nasira sa humigit-kumulang 3,500 na bisita na sumasaklaw sa parehong upload path, sa isang pumalpak na upload, at sa publish pagkatapos nito, at eksaktong ang natitirang file lang ang nabura.

Problema 2: masyadong matagal bago lumabas ang republish

Kahit maayos ang upload, mabagal lumabas ang mga pagbabago. Itinatago ng edge ang kopya ng page sa loob ng 60 segundo at ng bawat ibang file sa loob ng isang araw, at sinasabi rin nito sa mga browser na gawin ang ganoon. Ang mga file na may nakapirming pangalan, gaya ng logo.png, font, o anumang nasa public/ folder, ay maaaring magpakita ng lumang bersyon hanggang isang araw pagkatapos ng republish.

Ang ayos: mga kopya ng file sa ilalim ng build

Kapag nagtanong ang edge sa aming API kung nasaan ang site, may kasama na ngayong build marker ang sagot na nagbabago sa tuwing may publish na natatapos. Inilalagay ng edge ang kopya nito sa ilalim ng marker na iyon. Kaya ang publish ay nagiging bagong set ng cache keys sa sandaling mag-expire ang 30-segundong lookup ng edge. Hindi na nahahanap ang mga lumang kopya, kaya maaaring panatilihin ng edge ang mga kopya sa loob ng isang araw nang hindi kailanman naghahatid ng isa na lampas sa publish na pumalit dito.

Dalawang magkaibang patakaran ang ibinibigay sa browser:

Hashed na build output, mga file gaya ng assets/index-CzLcxDO8.js na nagbabago ang pangalan kapag nagbago ang nilalaman, ay naka-cache nang isang taon at minarkahang immutable. Hindi ito maaaring maging lipas sa ilalim ng pangalang iyon.
Lahat ng iba, mga page at mga file na may nakapirming pangalan gaya ng logo, ay minarkahang no-cache, ibig sabihin ay "tingnan muna bago gamitin". Kung walang nagbago, ang sagot ay maliit na 304 Not Modified na walang body, ngayong iginagalang na namin ang If-None-Match check ng browser.

Kailangang maingat ang pagkilala sa dalawa: ang file na kinopya mula sa public/assets/ ay nananatili sa sariling pangalan nito, at ang pag-cache sa assets/logo.png ng isang taon ay mag-iipit ng lumang logo sa loob ng isang taon. Kaya ang file ay bibilangin lamang na hashed kung nasa build output folder ito at may segment ang pangalan nito na mukhang hash, hindi isang ordinaryong salita.

Sa lokal, nakita ang bagong page at logo 6 segundo pagkatapos maging live ang publish. Dati, 60 segundo para sa page at isang araw para sa logo.

Dalawang mas maliit na ayos sa daan

Blangkong page mula sa HEAD requests. Ang HEAD request ay humihingi ng headers ng page nang walang body nito. Itinatago namin ang mga walang lamang response na iyon, kaya ang susunod na bisita sa page na iyon ay nakakakuha ng blangkong page. Hindi na itinatago sa cache ang mga HEAD response.
Tunay na page para sa "walang laman dito". Ang address na walang app ay dating nagbibigay ng plain-text na "This published app is offline or the link was not found" na may 502 error code. Ngayon, tamang page na ang nakukuha nito, "There's no app here", na may 404 status at daan pabalik sa Mythex para sa may-ari. Ang hindi kilalang custom domain ay nakakakuha ng parehong page.

Ang natutunan namin

Mahalaga ang pagkakasunod-sunod bilang bahagi ng pagiging tama. Ang parehong mga file na ina-upload sa ibang pagkakasunod-sunod ang pagkakaiba ng sirang site at gumaganang site.
Magbura nang huli, at ang alam mo lang. Ligtas ang pagbura gamit ang listahang kinuha bago ang upload; ang pag-empty ng folder at pag-asang matatapos ang upload ay hindi ligtas.
Mag-cache ayon sa bersyon, hindi ayon sa oras. Ang expiry time ay hula kung kailan nagbabago ang nilalaman. Ang key na nagbabago kasama ng build ay katotohanan.

Kaugnay: nananatiling live na ang na-publish mong app habang nire-republish mo ito. Higit pa tungkol sa publishing sa docs.