Статичните сајтови сега остануваат достапни додека се објавуваат повторно

Повторното објавување статичен сајт на Mythex порано прво ги бришеше живите датотеки и дури потоа го качуваше новиот билд, па за времето на качувањето дел од посетителите добиваа страница 404 или страница чии скрипти недостасуваа. Неуспешно качување можеше да остави сајтот празен или наполовина нов. Сега новиот билд се запишува преку стариот, страниците последни, а остатоците се отстрануваат неколку минути подоцна. Втора поправка прави повторното објавување да се појави во рок од секунди, наместо во рок од една минута — или, за датотеки како логото, до еден ден.

Како се послужува статичен сајт

Статичен сајт е оној што се состои само од датотеки: HTML страници, JavaScript, CSS и слики. Кога ќе го објавите на Mythex, ние го градиме, резултатот го качуваме во објектно складиште во папка за вашиот сајт и го послужуваме преку мрежа на edge сервери — сервери блиску до посетителите, кои ги преземаат датотеките од складиштето и одредено време чуваат копии од нив. (Ако ова ви е ново, нашиот водич за што е CDN ја објаснува идејата.)

Две работи беа погрешни: редоследот по кој повторното објавување ги менуваше датотеките и колку долго се чуваа стари копии.

Проблем 1: качувањето прво го празнеше сајтот

Повторното објавување ја бришеше целата содржина на папката на сајтот, па потоа го качуваше новиот билд. Сè додека качувањето траеше — 12 секунди за сајт со 250 датотеки во нашиот локален тест — посетител чие барање не беше веќе кеширано на edge серверот добиваше 404, или HTML страница чии скрипти враќаа 404.

Неуспешното качување беше уште полошо. Папката веќе беше празна, а на едниот од двата пата на качување новиот index.html можеше да се појави пред датотеката што не успеала. Објавување пријавено како неуспешно можеше да остави наполовина нов сајт во живо.

Поправката: запиши преку, страниците последни, бриши подоцна

1. Не брише прво. Новиот билд се качува врз стариот.
2. Средствата пред страниците. Страницата ги наведува скриптите и стиловите што ги бара, па страниците се качуваат последни. Додека не пристигнат новите страници, посетителите ја добиваат старата страница, која ги наведува старите средства, а тие уште се таму. Кога ќе пристигнат новите страници, новите средства на кои се повикуваат веќе се на место.
3. Остатоците ги бришеме подоцна. Пред качувањето ја евидентираме листата на датотеки од кои се состои сајтот. Три минути по успешното качување, секоја датотека од таа листа што новиот билд не ја презапишал се брише. Три минути е подолго од 60-те секунди колку страница може да се кешира на edge серверот и во прелистувачот, па посетител што уште ја држи старата страница може да ги најде средствата што таа ги наведува.
4. Во сомнеж, не брише ништо. Ако евидентирањето пред качувањето не успее, ништо не се брише. Остатоците од датотеки не прават штета, а следното објавување ги чисти. Бришењето без да знаеме што имало таму е начинот сајтот да остане празен.

Неуспешното качување сега го остава претходниот сајт точно онака каков што бил.

Ова го тестиравме од крај до крај локално, со вистинската скрипта за качување, вистинската рута за качување и вистинското послужување од складиштето, а посетителите пристигнуваа со ладен edge кеш. Со стариот код, 55 од 91 посети беа расипани при повторно објавување, а 61 од 92 при неуспешно. Со новиот код, 0 беа расипани во околу 3.500 посети, што ги опфаќаа двата пата на качување, неуспешното качување и објавувањето после него — и точно остатоците беа отстранети.

Проблем 2: повторното објавување се појавуваше премногу бавно

Дури и кога качувањето минуваше добро, промените се појавуваа бавно. Edge серверот ја чуваше копијата на страница 60 секунди, а на секоја друга датотека по еден ден, и тоа им го кажуваше и на прелистувачите. Датотеките со фиксно име — logo.png, фонт или било што од папката public/ — можеа да ја прикажуваат старата верзија до еден ден по повторното објавување.

Поправката: копии на датотеки под билдот

Кога edge серверот ќе побара од нашиот API каде живее еден сајт, одговорот сега вклучува маркер на билдот, кој се менува при секое објавување. Edge серверот своите копии ги складира под тој маркер. Објавувањето затоа станува сосема нов сет клучеви во кешот штом ќе истече 30-секундното барање на edge серверот. Старите копии едноставно повеќе не се наоѓаат, па edge серверот може да ги чува копиите до еден ден, а никогаш да не послужи копија од објавувањето што ја заменило.

Прелистувачите добиваат две различни правила:

• Хеширан излез од билдот — датотеки како assets/index-CzLcxDO8.js, чие име се менува кога и содржината — се кешира една година и се означува како immutable. Под тоа име никогаш не може да застари.
• Сè друго — страниците и датотеките со фиксно име, како логото — се означени со no-cache, што значи „провери пред употреба“. Ако ништо не се променило, одговорот е мал 304 Not Modified без содржина, откако сега ја почитуваме проверката If-None-Match на прелистувачот.

Разликувањето на двете бара внимание: датотека копирана од public/assets/ го задржува своето име, а кеширањето на assets/logo.png една година би го задржало стариот логотип една година. Затоа датотека се смета за хеширана само ако се наоѓа во папка со излез од билдот и нејзиното име има сегмент што изгледа како хеш, а не обичен збор.

Локално, новата страница и логото беа видливи 6 секунди по објавувањето. Порано тоа беше 60 секунди за страницата и еден ден за логото.

Две помали поправки во тек

• Празни страници од HEAD барања. HEAD барањето ги бара заглавијата на страницата без нејзината содржина. Тие празни одговори ги кеширавме, па следниот посетител на таа страница добиваше празна страница. HEAD одговорите повеќе не се кешираат.
• Вистинска страница за „тука нема ништо“. Адреса без апликација порано добиваше обичен текст „This published app is offline or the link was not found“ со код на грешка 502. Сега добива соодветна страница, „There's no app here“, со статус 404 и враќање на Mythex за сопственикот. Непознатите сопствени домени добиваат истата страница.

Што научивме

• Редоследот е дел од исправноста. Истите датотеки, качени во друг редослед, се разликата помеѓу расипан и функционален сајт.
• Бриши доцна и само она што го знаеш. Бришењето со листа направена пред качувањето е безбедно; празнењето на папка и надежта дека качувањето ќе заврши не се.
• Кеширај според верзијата, не според времето. Времињата на истекување се претпоставка за тоа кога се менува содржината. Клуч што се менува со билдот е факт.

Поврзано: вашата објавена апликација сега останува достапна додека ја објавувате повторно. Повеќе за објавувањето во документацијата.