Zapier या Make ऑटोमेशन को नए जियोकोडिंग होस्ट पर माइग्रेट करना
जियोकोडिंग चरण पर बने नो-कोड ऑटोमेशन के लिए कस्टम कोड से अलग माइग्रेशन तरीका चाहिए। यह बदलाव कैसे संभालें, यहाँ बताया गया है।
मोबाइल ऐप की जियोकोडिंग कॉल माइग्रेट करना
सीधे मोबाइल ऐप से की जाने वाली जियोकोडिंग कॉल को माइग्रेट करने में कुछ ऐसी बाधाएँ आती हैं जिनसे पूरी तरह सर्वर-साइड माइग्रेशन को नहीं जूझना पड़ता, और शुरू करने से पहले उन्हें स्पष्ट रूप से पहचान लेना सार्थक है, क्योंकि वे योजना का स्वरूप बदल देती हैं।
पहली है रिलीज़ की गति। सर्वर-साइड बदलाव डिप्लॉय होते ही लाइव हो सकता है। मोबाइल ऐप के बदलाव को ऐप स्टोर समीक्षा से गुज़रना पड़ता है, और फिर उसका अपनाया जाना इस पर निर्भर करता है कि उपयोगकर्ता सचमुच अपडेट करें, जिसमें कई ऐप के लिए इंस्टॉल किए गए ज़्यादातर उपयोगकर्ताओं तक पहुँचने में हफ़्ते लगते हैं और सभी तक पहुँचने में काफ़ी ज़्यादा समय लग सकता है। मोबाइल ऐप की किसी भी माइग्रेशन योजना में दो प्रदाताओं, या ऐप के दो संस्करणों, को साथ-साथ उससे ज़्यादा समय तक चलाने का हिसाब रखना होगा जितना सर्वर माइग्रेशन में आम तौर पर लगता है।
दूसरी है क्रेडेंशियल का उजागर होना। मोबाइल ऐप बाइनरी में सीधे डाली गई API कुंजी को कोई भी निकाल सकता है जिसके पास देखने की वजह हो, और यह एक सुरक्षा पहलू है, चाहे कोई भी प्रदाता हो। अगर आपका मौजूदा इंटीग्रेशन डाली गई कुंजी के साथ सीधे क्लाइंट से जियोकोडिंग API को कॉल करता है, तो माइग्रेशन उस पैटर्न पर दोबारा सोचने और कॉल को अपने बैकएंड के पीछे ले जाने का उचित मौका है, भले ही इससे थोड़ी लेटेंसी और थोड़ा बैकएंड का काम बढ़ता है।
कुछ व्यावहारिक कदम जो ज़्यादातर मोबाइल माइग्रेशन पर लागू होते हैं:
- अगर कॉल को सर्वर-साइड ले जा रहे हैं, तो पहले नया बैकएंड एंडपॉइंट डिज़ाइन करें और मोबाइल ऐप को अपने API से जोड़ें, इसकी चिंता करने से पहले कि उसके पीछे कौन सा प्रदाता है, जिससे ऐप की तरफ़ का बदलाव प्रदाता की तरफ़ के बदलाव से पूरी तरह अलग हो जाता है
- अगर कॉल को क्लाइंट-साइड ही रख रहे हैं, तो API होस्ट और कुंजी को हार्डकोड करने के बजाय बिल्ड-टाइम कॉन्फ़िगरेशन मान का उपयोग करें, ताकि भविष्य के माइग्रेशन में फिर से पूरे कोडबेस में किसी शाब्दिक स्ट्रिंग को ढूँढकर बदलना न पड़े
- अगर आप बदलाव की अवधि में दोनों प्रदाताओं को सपोर्ट करने की योजना बना रहे हैं, तो सिर्फ़ नवीनतम बिल्ड पर नहीं, बल्कि अब भी इस्तेमाल हो रहे असली पुराने ऐप संस्करणों पर परीक्षण करें, क्योंकि किसी पुराने, जल्द बंद होने वाले होस्ट को कॉल करता पुराना ऐप संस्करण एक यथार्थवादी स्थिति है जिसके लिए यह स्पष्ट निर्णय ज़रूरी है कि उसे कितने समय तक सपोर्ट करना है
My Geocode के ऑथेंटिकेशन विकल्प (X-API-Key हेडर, Authorization: Bearer हेडर, HTTP Basic auth या क्वेरी पैरामीटर) एक जैसे काम करते हैं, चाहे अनुरोध सीधे मोबाइल क्लाइंट से आए या आपके अपने बैकएंड से जो कॉल को प्रॉक्सी करता है, इसलिए यह खास निर्णय (क्लाइंट-साइड बनाम सर्वर-साइड) किसी भी स्थिति में यह सीमित नहीं करता कि कौन सी ऑथेंटिकेशन शैली उपलब्ध है। कोटा का उपयोग हर रिस्पॉन्स पर X-Quota-Used और X-Quota-Reset जैसे हेडर के ज़रिए दिखता है, जिनका विवरण /docs/rate-limits/ पर है, और अगर आप अनुरोध जहाँ से आते हैं वहाँ से इन हेडर तक पहुँच सकते हैं, तो ये मोबाइल माइग्रेशन के रोलआउट की प्रगति पर नज़र रखने के लिए उपयोगी हैं।
मोबाइल माइग्रेशन में सर्वर-साइड माइग्रेशन से ज़्यादा धैर्य का फल मिलता है, मुख्य रूप से इसलिए क्योंकि रिलीज़ और अपनाने का चक्र एक ऐसी समय-सीमा थोपता है जिसे आप तेज़ काम करके छोटा नहीं कर सकते। शुरू से ही बदलाव की लंबी अवधि की योजना बनाने से उस निराशा से बचा जा सकता है जो ऐसी प्रक्रिया से सर्वर-साइड माइग्रेशन जैसी गति की उम्मीद करने पर होती है जो ढाँचागत रूप से उतनी तेज़ नहीं चल सकती।