तुमचे published अ‍ॅप republish करताना आता चालू राहते

Mythex वर तुम्ही अ‍ॅप republish करता तेव्हा नवीन build तयार होईपर्यंत तुमची live साइट आधीची आवृत्ती देत राहते, मग नवीन आवृत्तीवर वळते. या बदलापूर्वी republish केल्यावर build संपेपर्यंत साइट बंद होत असे — भेट देणाऱ्यांना "This published app is offline or the link was not found" दिसे आणि एका मिनिटानंतर reload केल्यावर तेच पेज पुन्हा चालत असे. आम्ही live अ‍ॅप चुकीने offline दिसण्याच्या आणखी दोन मार्गांचेही निराकरण केले.

1. Republish केल्याने तुमची साइट बंद होत नाही

पडद्यामागे प्रत्येक published अ‍ॅपसाठी एक नोंद असते जी सांगते कोणता build सर्व्ह करायचा. Republish त्या नोंदीचा पुन्हा वापर करून ती "building" म्हणून चिन्हांकित करत असे — आणि आमच्या edge चा जो भाग भेट देणाऱ्यांना routing करतो तो फक्त "live" म्हणून चिन्हांकित नोंदी सर्व्ह करत असे. त्यामुळे प्रत्येक republish build संपेपर्यंत साइट गायब करत असे. एका छोट्या चाचणी अ‍ॅपवर आम्ही हे पुनरुत्पादित केले: प्रत्येक republish वेळी सुमारे 50 सेकंद offline.

आता, आधीपासून live असलेल्या अ‍ॅपवर republish सुरू झाले की नोंद लक्षात ठेवते की आधीचा build अस्तित्वात आहे, आणि त्याकडेच निर्देश करत राहते. Edge नवीन build तयार होत असताना आधीचा build सर्व्ह करते, आणि नवीन build यशस्वी झाल्यावरच pointer नवीन build कडे सरकतो. नवीन build अयशस्वी झाला तर तुमच्या भेट देणाऱ्यांना काहीही कळत नाही — जुनी आवृत्ती चालू राहते.

पहिले publish, किंवा pause केलेले किंवा unpublish केलेले अ‍ॅप republish करणे, तरीही build संपल्यावरच live होते — दाखवण्यासारखी आधीची आवृत्ती नसते.

2. थोडासा अडथळा आता "not found" सारखा दिसत नाही

तुमच्या published अ‍ॅपच्या समोरील सेवा प्रत्येक साइट कुठे आहे हे आमच्या API ला विचारते. पूर्वी ती कोणतेही यशस्वी नसलेले उत्तर — क्षणिक सर्व्हर त्रुटी, तुटलेले कनेक्शन — "ही साइट अस्तित्वात नाही" असे मानत असे आणि offline पेज दाखवत असे. एक सेकंदानंतर reload केल्यावर ते चालत असे, ज्यामुळे गोंधळ होत असे.

आता फक्त खरे "not found" उत्तर not found म्हणून मोजले जाते:

• इतर कोणतेही अपयश एकदा पुन्हा प्रयत्न केले जाते.
• तरीही अपयश आले तर edge शेवटच्या माहीत असलेल्या चांगल्या उत्तरावरून एका तासापर्यंत साइट सर्व्ह करतो.
• कधीच उत्तर मिळाले नसेल तरच तो "तात्पुरते उपलब्ध नाही" पेज दाखवतो — कधीही "not found" नाही.

Custom domains आमच्या production आणि staging प्रणालींना समांतर विचारतात, त्यामुळे हळू staging सर्व्हर कधीही production domain ला थांबवू शकत नाही.

3. थांबवलेले अ‍ॅप म्हणते की ते थांबवले आहे

Published अ‍ॅप्स तुमच्या क्रेडिट शिल्लकीवर चालतात. ती संपली तर तुम्ही पुन्हा भरेपर्यंत अ‍ॅप थांबवले जाते — आणि तुम्ही भरल्यावर ते आपोआप परत येते. पण थांबवलेले अ‍ॅप पूर्वी हटवलेल्या अ‍ॅपसारखेच दिसत असे.

आता थांबवलेल्या अ‍ॅपच्या भेट देणाऱ्याला "हे अ‍ॅप थांबवले आहे" दिसते, मालकासाठी परत जाण्याच्या मार्गासह, आणि तो प्रतिसाद कधीही cache होत नाही, त्यामुळे पुन्हा सुरू होताच अ‍ॅप उपलब्ध होते. अ‍ॅप दुसऱ्या कारणाने उपलब्ध नसेल तर भेट देणाऱ्यांना "हे अ‍ॅप उपलब्ध नाही" दिसते — का ते सांगितले न जाता.

हे का महत्त्वाचे आहे

Published अ‍ॅप म्हणजे तुम्ही शेअर केलेली गोष्ट: bio लिंकमध्ये, व्यवसाय कार्डावर, तुमच्या पहिल्या ग्राहकांसोबत. तिने खऱ्या वेबसाइटसारखे वागले पाहिजे — तुम्ही ती सुधारत असताना चालू राहावे, एका अडथळ्यातून टिकावे, आणि थांबवलेले असताना प्रामाणिक असावे.

अधिक publishing माहिती docs मध्ये: how to publish आणि hosting limits. आणि त्याच कल्पनेची infrastructure बाजू: आमचे स्वतःचे deploys शून्य 502s पर्यंत कसे आणले.