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