स्टैटिक साइट्स अब रीपब्लिश होते समय भी चालू रहती हैं

Mythex पर स्टैटिक साइट को रीपब्लिश करने से पहले लाइव फ़ाइलें मिटा दी जाती थीं और फिर नया बिल्ड अपलोड होता था, इसलिए अपलोड के दौरान कुछ विज़िटर्स को 404 पेज या ऐसा पेज मिलता था जिसकी स्क्रिप्ट गायब थी। विफल अपलोड साइट को खाली या आधी नई छोड़ सकता था। अब नया बिल्ड पुराने के ऊपर लिखा जाता है, पेज सबसे आख़िर में, और बचे हुए फ़ाइलें कुछ मिनट बाद हटाई जाती हैं। एक और सुधार से रीपब्लिश एक मिनट के बजाय सेकंडों में दिखता है, या लोगो जैसी फ़ाइलों के लिए अधिकतम एक दिन में।

स्टैटिक साइट कैसे सर्व होती है

स्टैटिक साइट वह है जो केवल फ़ाइलों से बनी है: HTML पेज, JavaScript, CSS, इमेज। Mythex पर पब्लिश करने पर हम उसे बिल्ड करते हैं, आउटपुट को आपकी साइट के फ़ोल्डर के तहत ऑब्जेक्ट स्टोरेज में अपलोड करते हैं, और उसे एक एज नेटवर्क के ज़रिए सर्व करते हैं: आपके विज़िटर्स के नज़दीक के सर्वर जो स्टोरेज से फ़ाइलें लाते हैं और कुछ समय के लिए उनकी कॉपी रखते हैं। (अगर यह नया है, तो हमारी गाइड CDN क्या है यह विचार समझाती है।)

दो चीज़ें गलत थीं: रीपब्लिश में फ़ाइलें किस क्रम में बदलती थीं, और पुरानी कॉपी कितनी देर रखी जाती थी।

समस्या 1: अपलोड ने पहले साइट खाली कर दी

रीपब्लिश साइट के फ़ोल्डर की हर चीज़ मिटा देता था, फिर नया बिल्ड अपलोड करता था। जितनी देर अपलोड चलता था, यानी हमारे लोकल टेस्ट में 250 फ़ाइलों की साइट के लिए 12 सेकंड, किसी ऐसे विज़िटर को जिसका अनुरोध एज पर पहले से कैश में नहीं था, 404 मिलता था, या ऐसा HTML पेज जिसकी स्क्रिप्ट 404 देती थीं।

विफल अपलोड और बुरा था। फ़ोल्डर पहले ही खाली हो चुका था, और दो अपलोड पथों में से एक पर नया index.html उस फ़ाइल से पहले पहुँच सकता था जो विफल हुई। विफल बताए गए पब्लिश के बाद आधी नई साइट लाइव रह सकती थी।

समाधान: ऊपर लिखें, पेज आख़िर में, बचे हुए बाद में हटाएँ

1. पहले न मिटाएँ। नया बिल्ड पुराने के ऊपर अपलोड होता है।
2. पेज से पहले एसेट्स। पेज को किन स्क्रिप्ट्स और स्टाइल्स की ज़रूरत है यह वह बताता है, इसलिए पेज सबसे आख़िर में जाते हैं। नए पेज पहुँचने तक विज़िटर्स को पुराना पेज मिलता है, जो पुराने एसेट्स का नाम लेता है, और वे अब भी मौजूद हैं। पेज पहुँचते ही उनके नाम लिए गए नए एसेट्स पहले से जगह पर होते हैं।
3. बचे हुए बाद में हटाएँ। अपलोड से पहले हम सूची बनाते हैं कि साइट किन चीज़ों से बनी है। सफल अपलोड के तीन मिनट बाद, उस सूची की कोई भी ऐसी फ़ाइल जिसे नए बिल्ड ने दोबारा नहीं लिखा, हटा दी जाती है। तीन मिनट उस 60 सेकंड से लंबे हैं जितनी देर कोई पेज एज और ब्राउज़र में कैश रह सकता है, इसलिए पुराना पेज थामे हुए विज़िटर को उसके एसेट्स मिल सकते हैं।
4. संदेह हो तो कुछ न मिटाएँ। अगर अपलोड से पहले की सूची लेना विफल हो, तो कुछ भी नहीं हटाया जाता। बची फ़ाइलें नुकसान नहीं करतीं, और अगला पब्लिश उन्हें साफ़ कर देता है। बिना जाने कि क्या था, मिटाना ही वह तरीका है जिससे साइट खाली हो जाती है।

अब विफल अपलोड पिछली साइट को बिल्कुल वैसा ही छोड़ता है जैसी वह थी।

हमने इसे स्थानीय रूप से एंड-टू-एंड टेस्ट किया, असली अपलोड स्क्रिप्ट, असली अपलोड रूट और स्टोरेज सर्विंग के साथ, और ऐसे विज़िटर्स के साथ जिनके एज कैश ठंडे थे। पुराने कोड के साथ, रीपब्लिश के दौरान 91 में से 55 विज़िट टूटी हुई थीं, और विफल रीपब्लिश के दौरान 92 में से 61। नए कोड के साथ, दोनों अपलोड पथों, एक विफल अपलोड और उसके बाद के पब्लिश में लगभग 3,500 विज़िट में 0 टूटीं, और ठीक वही बचे हुए फ़ाइलें हटीं।

समस्या 2: रीपब्लिश को दिखने में बहुत समय लगता था

अपलोड ठीक होने पर भी बदलाव देर से दिखते थे। एज किसी पेज की कॉपी 60 सेकंड और बाकी हर फ़ाइल की एक दिन रखता था, और ब्राउज़र को भी यही बताता था। logo.png, फ़ॉन्ट, या public/ फ़ोल्डर से कोई भी चीज़, जिनका नाम तय है, रीपब्लिश के बाद एक दिन तक पुराना वर्शन दिखा सकती थीं।

समाधान: बिल्ड के नीचे फ़ाइल कॉपियाँ

जब एज हमारे API से पूछता है कि साइट कहाँ है, तो जवाब में अब एक बिल्ड मार्कर होता है जो हर बार बदलता है जब कोई पब्लिश लागू होता है। एज अपनी कॉपियाँ उसी मार्कर के नीचे रखता है। इसलिए एज की 30-सेकंड वाली लुकअप अवधि खत्म होते ही पब्लिश नए कैश कीज़ का पूरा नया सेट बन जाता है। पुरानी कॉपियाँ फिर कभी नहीं मिलतीं, इसलिए एज उन्हें एक दिन तक रख सकता है, और कभी उस पब्लिश के बाद की नहीं सर्व करता जिसने उन्हें बदला।

ब्राउज़र के लिए दो अलग नियम हैं:

• हैश वाला बिल्ड आउटपुट — जैसे 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 पर वापस जाने का रास्ता। अज्ञात कस्टम डोमेन को भी यही पेज मिलता है।

हमने क्या सीखा

• क्रम भी सही होने का हिस्सा है। वही फ़ाइलें अगर अलग क्रम में अपलोड हों, तो टूटी साइट और काम करती साइट में फ़र्क हो जाता है।
• देर से हटाएँ, और केवल वही जो आप जानते हैं। अपलोड से पहले ली गई सूची के साथ हटाना सुरक्षित है; फ़ोल्डर खाली करके उम्मीद करना कि अपलोड पूरा हो जाएगा, सुरक्षित नहीं है।
• समय नहीं, संस्करण के अनुसार कैश करें। समाप्ति समय इस बारे में अनुमान हैं कि सामग्री कब बदलती है। जो की बिल्ड के साथ बदलती है, वह एक तथ्य है।

संबंधित: आपका पब्लिश किया ऐप रीपब्लिश के दौरान भी कैसे चालू रहता है। पब्लिशिंग के बारे में और डॉक्स में।