स्टॅटिक साइट्स पुन्हा प्रकाशित होत असतानाही सुरू राहतात

Mythex वर स्टॅटिक साइट पुन्हा प्रकाशित करताना आधी live फाइल्स हटवल्या जायच्या आणि मग नवा build अपलोड व्हायचा, त्यामुळे अपलोडच्या काळात काही visitors ला 404 पान किंवा गहाळ स्क्रिप्ट्स असलेले पान मिळत होते. अपलोड अयशस्वी झाला तर साइट रिकामी किंवा अर्धवट नवीन राहू शकत होती. आता नवा build जुन्यावर लिहिला जातो, पाने शेवटी, आणि उरलेल्या फाइल्स काही मिनिटांनी काढल्या जातात. दुसरी दुरुस्ती पुन्हा प्रकाशन एका मिनिटाऐवजी काही सेकंदात दिसेल असे करते — किंवा लोगोसारख्या फाइल्ससाठी एका दिवसापर्यंत लागणारा वेळ कमी करते.

स्टॅटिक साइट कशी सेवा होते

स्टॅटिक साइट म्हणजे फक्त फाइल्सची साइट: HTML पाने, JavaScript, CSS, प्रतिमा. Mythex वर ती प्रकाशित केली की आम्ही ती build करतो, आउटपुट तुमच्या साइटच्या फोल्डरखाली object storage मध्ये अपलोड करतो, आणि edge network मधून सेवा करतो — तुमच्या visitors जवळचे servers, जे storage मधून फाइल्स आणतात आणि काही काळ त्यांच्या प्रती ठेवतात. (तुम्ही नवीन असाल तर CDN म्हणजे काय हे मार्गदर्शक कल्पना समजावते.)

दोन गोष्टी चुकीच्या होत्या: पुन्हा प्रकाशनात फाइल्स कोणत्या क्रमाने बदलल्या जात होत्या, आणि जुन्या प्रती किती काळ ठेवल्या जात होत्या.

समस्या 1: अपलोडने आधी साइट रिकामी केली

पुन्हा प्रकाशनात साइटच्या फोल्डरमधील सर्व काही हटवले जायचे, आणि मग नवा build अपलोड व्हायचा. अपलोड जितका वेळ चालायचा — आमच्या स्थानिक चाचणीत 250 फाइल्सच्या साइटसाठी 12 सेकंद — तोपर्यंत edge वर आधीच cache नसलेली विनंती करणाऱ्या visitor ला 404, किंवा ज्या HTML पानाच्या स्क्रिप्ट्स 404 देत होत्या ते पान मिळत होते.

अयशस्वी अपलोड आणखी वाईट होता. फोल्डर आधीच रिकामा झालेला होता, आणि एका अपलोड मार्गावर नवीन index.html अयशस्वी फाइलच्या आधीच येऊ शकत होती. अयशस्वी म्हणून नोंदलेला publish अर्धवट नवी साइट live ठेवू शकत होता.

उपाय: वर लिहा, पाने शेवटी, नंतर काढा

1. आधी हटवू नका. नवा build जुन्यावर अपलोड केला जातो.
2. Assets आधी, पाने नंतर. पान त्याला लागणाऱ्या स्क्रिप्ट्स आणि styles चे नाव घेते, म्हणून पाने शेवटी जातात. नवी पाने येईपर्यंत visitors ला जुने पान मिळते, जे जुन्या assets चे नाव घेते, आणि ते assets अजूनही तिथे असतात. नवी पाने आल्यावर ती नाव घेत असलेले नवे assets आधीच जागी असतात.
3. उरलेल्या फाइल्स नंतर काढा. अपलोडपूर्वी आम्ही साइट कशापासून बनलेली आहे ते यादीत घेतो. यशस्वी अपलोडनंतर तीन मिनिटांनी, त्या यादीतील जे काही नवीन build ने पुन्हा लिहिले नाही ते हटवले जाते. तीन मिनिटे edge आणि browser मध्ये पान 60 सेकंद cache होऊ शकते त्यापेक्षा जास्त आहेत, त्यामुळे जुने पान धरून असलेला visitor त्यातील assets शोधू शकतो.
4. शंका असल्यास, काहीही हटवू नका. अपलोडपूर्वीची यादी अयशस्वी झाली तर काहीही काढले जात नाही. उरलेल्या फाइल्स निरुपद्रवी असतात, आणि पुढील publish त्या साफ करतो. काय होते हे माहिती नसताना हटवणे हाच साइट रिकामी होण्याचा मार्ग आहे.

आता अयशस्वी अपलोड मागील साइट अगदी जशीच्या तशी ठेवतो.

आम्ही हे शेवटपर्यंत स्थानिकरित्या तपासले, खरे अपलोड script, खरा upload route आणि storage सेवा वापरून, आणि cold edge cache असलेल्या visitors सह. जुन्या कोडने पुन्हा प्रकाशन दरम्यान 91 पैकी 55 भेटी तुटल्या आणि अयशस्वी दरम्यान 92 पैकी 61. नवीन कोडने दोन्ही अपलोड मार्ग, अयशस्वी अपलोड आणि त्यानंतरचे publish मिळून सुमारे 3,500 भेटींमध्ये 0 तुटल्या — आणि नेमक्या उरलेल्या फाइल्स काढल्या गेल्या.

समस्या 2: पुन्हा प्रकाशित होण्यास खूप वेळ लागत होता

अपलोड व्यवस्थित झाला तरीही बदल दिसायला वेळ लागत होता. Edge प्रत्येक पान 60 सेकंद आणि इतर प्रत्येक फाइल एक दिवस ठेवत होता, आणि browsers ना तसेच सांगत होता. निश्चित नाव असलेल्या फाइल्स — logo.png, फॉन्ट, public/ फोल्डरमधील काहीही — पुन्हा प्रकाशनानंतर एक दिवसापर्यंत जुनी आवृत्ती दाखवू शकत होत्या.

उपाय: build खाली फाइल्सच्या प्रती

Edge आमच्या API ला साइट कुठे आहे हे विचारतो, तेव्हा उत्तरात आता एक build marker असतो, जो प्रत्येक वेळी publish लागू झाल्यावर बदलतो. Edge त्याच्या प्रती त्या marker खाली साठवतो. त्यामुळे edge चा 30 सेकंदांचा lookup संपताच प्रत्येक publish नवीन cache keys चा संच बनतो. जुन्या प्रती पुन्हा कधीच सापडत नाहीत, त्यामुळे edge प्रती एक दिवस ठेवू शकतो आणि त्यांना बदलणाऱ्या publish नंतर कधीही जुनी प्रत देत नाही.

Browsers ना दोन वेगळे नियम मिळतात:

• Hashed build output — assets/index-CzLcxDO8.js सारख्या फाइल्स, ज्यांचे नाव content बदलते तेव्हा बदलते — एक वर्षासाठी cache होतात आणि immutable म्हणून चिन्हांकित होतात. त्या नावाखाली त्या कधीच जुन्या होऊ शकत नाहीत.
• बाकी सर्व — पाने आणि लोगोसारख्या निश्चित नावाच्या फाइल्स — no-cache चिन्हांकित होतात, म्हणजे "वापरण्यापूर्वी तपासा". काही बदलले नसेल तर उत्तर एक लहान 304 Not Modified असते, body शिवाय, कारण आता आम्ही browser चा If-None-Match तपासणी पाळतो.

या दोघांमध्ये फरक करण्यासाठी काळजी लागते: public/assets/ मधून कॉपी केलेली फाइल तिचे स्वतःचे नाव ठेवते, आणि assets/logo.png एका वर्षासाठी cache केला तर जुना लोगो एक वर्षभर अडकून राहील. म्हणून फाइल hashed मानली जाते फक्त जर ती build output फोल्डरमध्ये असेल आणि तिच्या नावात hash सारखा भाग असेल, साधा शब्द नव्हे.

स्थानिक चाचणीत नवीन पान आणि लोगो publish live झाल्यानंतर 6 सेकंदांनी दिसत होते. आधी पानासाठी 60 सेकंद आणि लोगोसाठी एक दिवस लागत होता.

प्रवासात केलेल्या दोन लहान दुरुस्त्या

• HEAD विनंत्यांमुळे रिकामी पाने. HEAD विनंती पानाचे headers body शिवाय मागते. आम्ही ती रिकामी उत्तरे cache करत होतो, त्यामुळे त्या पानाचा पुढचा visitor रिकामे पान पाहत होता. HEAD उत्तरे आता cache होत नाहीत.
• "काहीही नाही" साठी खरे पान. ज्या पत्त्यावर ॲप नव्हता तिथे पूर्वी "हे प्रकाशित ॲप ऑफलाइन आहे किंवा लिंक सापडली नाही" असा plain-text संदेश 502 error code सह मिळायचा. आता योग्य पान मिळते, "इथे कोणतेही ॲप नाही" असे, 404 status सह आणि मालकासाठी Mythex कडे परत जाण्याचा मार्ग. अज्ञात custom domains ना हेच पान मिळते.

आम्ही काय शिकलो

• क्रम म्हणजेही योग्यतेचा भाग. तेच फाइल्स वेगळ्या क्रमाने अपलोड केल्या तर तुटलेली आणि चालणारी साइट यात फरक पडतो.
• उशिरा हटवा, आणि जे माहीत आहे तेवढेच. अपलोडपूर्वी घेतलेल्या यादीने छाटणे सुरक्षित आहे; फोल्डर रिकामे करून अपलोड पूर्ण होईल अशी आशा करणे सुरक्षित नाही.
• वेळेने नव्हे, version ने cache करा. Expiry वेळ हा अंदाज आहे की content कधी बदलते. Build सोबत बदलणारी key ही वस्तुस्थिती आहे.

संबंधित: तुमचे प्रकाशित ॲप पुन्हा प्रकाशित करताना सुरू राहते. प्रकाशनावर अधिक माहितीसाठी docs पहा.