मैनुअल: अपनी पहली साइट पब्लिश करना

लाइव जाने के लिए चार क्लिक। दरवाज़े से पूरा होने तक तीस सेकंड। फ्री टियर पर हर अकाउंट में एक लाइव सर्वर-बैक्ड ऐप। किसी बिल्कुल नए सबडोमेन के पहले ही रिक्वेस्ट पर आधा सेकंड की अतिरिक्त लेटेंसी, और उसके बाद कभी नहीं। इनमें से तीन आंकड़े महज़ मामूली जानकारी हैं — जिन्हें सुनकर सिर हिलाओ और अगले अध्याय तक भूल जाओ। लेकिन "एक" वाला आंकड़ा असल में यह बदल देता है कि आपको कैसे काम करना चाहिए, इसलिए इसी अध्याय का ज़्यादातर हिस्सा इसी पर खर्च करना चाहता हूं।

सीमा एक क्यों है, न शून्य और न असीमित

ज़्यादातर नो-कोड टूल्स जो मुफ्त में फ्रंटएंड पब्लिश करने देते हैं, या तो सर्वर-बैक्ड ऐप्स को छूते ही नहीं, या उन्हें इतनी सख्ती से मीटर करते हैं कि "मुफ्त" सिर्फ एक तकनीकी शब्द बनकर रह जाता है। यहां, अकाउंट्स, डेटाबेस, या मल्टीप्लेयर स्टेट वाला बिल्ड ठीक उसी Publish बटन से पब्लिश होता है जैसे कोई स्टैटिक पेज, और सर्वर साइड को उसी एक एक्शन के हिस्से के रूप में होस्ट और मैनेज किया जाता है — कोई अलग डेटाबेस प्रोविज़निंग नहीं, कोई एनवायरनमेंट वेरिएबल्स कनेक्ट करने की ज़रूरत नहीं, और तीन दिन बाद यह पता चलने की नौबत नहीं कि प्रीव्यू में लॉगिन काम करता है लेकिन प्रोडक्शन में 500 एरर देता है क्योंकि बैकएंड कभी डिप्लॉय ही नहीं हुआ। यह वाकई सच है, और यही वजह है कि लोग सीमा से टकराने पर हैरान होते हैं: उस बिंदु तक सब कुछ असीमित महसूस होता था।

ऐसा नहीं है। फ्री टियर पर एक समय में आपको ठीक एक ही लाइव सर्वर-बैक्ड ऐप मिलता है। स्टैटिक बिल्ड इस गिनती में नहीं आते — जितने चाहें मार्केटिंग पेज और पोर्टफोलियो साइट्स पब्लिश करें, वहां कोई सीमा नहीं है। लेकिन जिस दूसरे बिल्ड को अपने खुद के डेटाबेस या स्थायी प्रोसेस की ज़रूरत हो, उसे अपनी बारी का इंतज़ार करना पड़ता है — पूरी तरह बना और प्रीव्यू करने लायक, बस अपने URL पर लाइव नहीं। अगर आप एक ही हफ्ते में तीन SaaS आइडिया पर काम कर रहे हैं, तो सिर्फ एक को असली कंप्यूट पर जगह मिलेगी; बाकी दो पूरे तैयार प्रोडक्ट होंगे लेकिन बिना किसी पते के। मुझे लगता है कि यह सीमा एक वाजिब जगह पर खींची गई है — एक स्टैटिक बंडल को एज पर सर्व करना प्लेटफ़ॉर्म के लिए लगभग मुफ्त है, जबकि एक वॉर्म सर्वर प्रोसेस ऐसा नहीं है — लेकिन इसका मतलब यह है कि कौन-सा आइडिया इस स्लॉट का हकदार है, यह फैसला Publish दबाने से पहले लेना होगा, न कि दो को एक साथ लाइव रखने की आदत लगने के बाद।

रिकॉर्ड के लिए, वे चार क्लिक

• बिल्ड के कार्ड पर, Publish चुनें।
• एक स्लग चुनें — आपका-उपयोगकर्ता-नाम में yourname.buildmidas.com। ली जा चुकी स्लग्स के लिए विकल्प सुझाए जाते हैं।
• कन्फर्म करें।
• कार्ड से URL कॉपी करें, या बाद में इसे अपने Published पेज पर खोजें।

कोई DNS नहीं, कोई बाहरी अकाउंट नहीं, प्रोपेगेशन का इंतज़ार नहीं। और उस आधे सेकंड के बारे में: यह कोई कतार या "24 घंटे बाद देखें" वाली देरी नहीं है, यह बस सामान्य CDN कैश वॉर्मिंग है। किसी नए सबडोमेन का पहला विज़िटर थोड़ी अतिरिक्त लेटेंसी झेल सकता है जब सबसे नज़दीकी एज नोड एसेट बंडल खींचता है; दूसरा विज़िटर, और उसके बाद हर कोई, इसे कैश से पाता है। व्यवहार में आपको यह महसूस नहीं होगा — आप पब्लिश करेंगे, लिंक टैप करेंगे, और यह पहले से ही इंस्टेंट महसूस होगा। मैं इसका ज़िक्र सिर्फ इसलिए कर रहा हूं क्योंकि जो कोई लोड टाइम के स्क्रीनशॉट लेकर काम करता है, वह आखिरकार पूछेगा कि पहली और दसवीं रिक्वेस्ट एक जैसी क्यों नहीं हैं, और अब आप जानते हैं।

स्लग वही एक फैसला है जिसके लिए रुकना उचित है

इस पूरे फ़्लो में बाकी सब कुछ यांत्रिक है; स्लग ही वह हिस्सा है जिसे किसी इंसान को बोलकर बताना या याद से टाइप करना पड़ता है, इसलिए इस पर थोड़ा सोचना उचित है। "demo-v2-final-final" इंटरनल टेस्टिंग के लिए ठीक है और क्लाइंट को टेक्स्ट करने के लिए बुरा विकल्प है। कन्फर्म करने से पहले URL को खुद से बोल कर देखें — riverside-cafe.buildmidas.com साफ़ लगता है, riverside-cafe-mvp2.buildmidas.com नहीं लगता। छोटे, सामान्य शब्द ऐसे प्लेटफ़ॉर्म पर जल्दी खत्म हो जाते हैं जो काफी समय से मौजूद है, इसीलिए ली जा चुकी स्लग पर खाली एरर की बजाय सुझाव मिलते हैं। कोई एक ले लें या ठुकरा दें, लेकिन जानबूझकर फैसला करें — मैंने लोगों को देखा है जो डेमो के बीच में बॉक्स में जो भी सुझाव आया उसे तुरंत लपक लेते हैं क्योंकि उन्हें फ़ौरन लिंक चाहिए होता है, और फिर महीनों तक एक अजीब नाम के साथ रहते हैं क्योंकि उसे ठीक करने का कोई स्वाभाविक मौका ही नहीं मिलता।

रीपब्लिश करने से जो लाइव है वह तब तक नहीं बदलता जब तक आप न कहें

यह तथ्य शुरू में ही समझ लेना ज़रूरी है: किसी पब्लिश हुए बिल्ड को एडिट करने से लाइव साइट नहीं बदलती। आप चीज़ें तोड़ सकते हैं, कोई जोखिम भरा लेआउट बदलाव आज़मा सकते हैं, एक हफ्ते तक इटरेट कर सकते हैं — जो URL पहले से क्लाइंट के पास बुकमार्क है वह वही सर्व करता रहेगा जो आपने आखिरी बार पब्लिश किया था, जब तक आप जानबूझकर दोबारा पब्लिश न करें।

यही आपकी पूरी रोलबैक कहानी है, और यह अच्छी इसलिए है क्योंकि यह उबाऊ है। वर्ज़न 6 में एक बग शिप होता है — एक फॉर्म जो चुपचाप सबमिट होना बंद कर देता है — और आप किसी रिवर्ट कमांड या सपोर्ट टिकट की ओर नहीं भागते। आप वर्ज़न हिस्ट्री खोलते हैं, वर्ज़न 5 ढूंढते हैं, उसे रीपब्लिश करते हैं। वही बटन, पुराना आर्टिफ़ैक्ट, लाइव URL तुरंत वापस पलट जाता है। फिर आप बिना किसी दबाव के वर्ज़न 6 को ठीक करते हैं, क्योंकि आपके काम करते समय प्रोडक्शन टूटा हुआ नहीं है। इसकी कीमत बस हर रिलीज़ पर एक अतिरिक्त क्लिक है, क्योंकि आपको याद रखना होता है कि एडिट अपने आप लाइव नहीं जाता, आपको खुद पब्लिश करना पड़ता है। उन टूल्स से इसकी तुलना करें जहां हर सेव लाइव होता है — डेमो में शानदार, असली इस्तेमाल के तीन हफ्तों बाद मुश्किल — और वह अतिरिक्त क्लिक हर बार करने लायक ट्रेड है।

अनपब्लिश का मतलब है URL रिज़ॉल्व होना बंद हो जाना, न कि "लिस्टिंग से हट जाना"

कई प्लेटफ़ॉर्म "अनपब्लिश" का इस्तेमाल इस अर्थ में करते हैं कि इसे किसी गैलरी पेज से छुपा दो जबकि URL चुपचाप सर्व करता रहे। यहां इसका मतलब है कि पता पूरी तरह बंद हो जाता है — कोई कैश्ड पेज नहीं, कोई प्लेसहोल्डर नहीं, कुछ भी रिज़ॉल्व नहीं होता। बिल्ड खुद हर वर्ज़न सहित सुरक्षित रहता है; बाद में रीपब्लिश करें तो वही स्लग ठीक वहीं वापस आ जाता है जहां आपने इसे छोड़ा था। मैंने इसका इस्तेमाल एक साधारण वजह से किया है (एक क्लाइंट एंगेजमेंट खत्म हो गया, कोई नहीं चाहता कि उनका पुराना लोगो किसी पब्लिक लिंक पर तैरता रहे) और एक कम साधारण वजह से भी (एक बिल्ड ने कुछ ऐसा लीक कर दिया जो नहीं होना चाहिए था, और उसे उतने समय में ऑफ़लाइन करना ज़रूरी था जितने में बटन दबाया जाता है, न कि उतने में जितने में होस्टिंग प्रोवाइडर के पास टिकट फ़ाइल किया जाता है)। दोनों स्थितियों को एक जैसी गारंटी चाहिए, और दोनों को यह मिलती है।

एक और चीज़ जिसे गड्डमड्ड न करें: पब्लिश करने से URL लिंक रखने वाले किसी भी व्यक्ति के लिए लाइव हो जाता है; क्या वह खोजने योग्य है — सार्वजनिक रूप से लिस्टेड, कभी-कभी Showcase में दिखाया गया — यह बिल्कुल अलग टॉगल है। कई वैध पब्लिश साइट्स को हमेशा सिर्फ लिंक-ओनली रहना चाहिए, और सार्वजनिक लिस्टिंग में शामिल एक बिल्ड नीचे से अब भी एक सामान्य पब्लिश साइट ही है, वही इतिहास और वही अनपब्लिश बटन के साथ।