कभी एक्सपायर न होने वाली API कुंजियों की समस्या
कई साल पहले जारी की गई कुंजी, जिसे कभी रोटेट नहीं किया गया और जो आज भी मान्य है, कोई सुविधा नहीं है। यह एक जोखिम है जिसे सालों से किसी ने वास्तव में देखा तक नहीं।
कम्पैटिबिलिटी होस्ट नए SDK से ज़्यादा मायने क्यों रखते हैं
हर API कंपनी चाहती है कि आप उसका SDK इंस्टॉल करें। SDK आपको बाँधकर रखता है। एक बार आपका कोडबेस किसी क्लाइंट लाइब्रेरी को इम्पोर्ट कर ले, उसके मेथड कॉल करे और उसके ऑब्जेक्ट ढाँचों पर निर्भर हो जाए, तो प्रोवाइडर बदलने का मतलब सिर्फ़ URL बदलना नहीं, बल्कि प्रोवाइडर से बात करने वाला कोड दोबारा लिखना होता है। यही बाँधकर रखना अक्सर एक मुफ़्त और सुविधाजनक SDK के पीछे का असली बिज़नेस मॉडल होता है, चाहे कोई इसे खुलकर कहे या न कहे।
हमने एक अलग तरीक़ा अपनाया। My Geocode के पास 17 कम्पैटिबिलिटी होस्ट हैं, और हर एक किसी दूसरे प्रोवाइडर के अपने अनुरोध और रिस्पॉन्स ढाँचे को दोहराता है। अगर आपका कोड पहले से किसी जाने-माने जियोकोडिंग API के एंडपॉइंट को कॉल करना और उसका JSON पार्स करना जानता है, तो आप उसी कोड को हमारे कम्पैटिबिलिटी होस्ट की ओर मोड़ सकते हैं और वह काम करता रहेगा। न कोई SDK इंस्टॉल करना, न रिस्पॉन्स पार्सिंग दोबारा लिखना, न कोई मालिकाना ऑब्जेक्ट मॉडल सीखना।
यह तब तक छोटी बात लगती है जब तक आपने किसी प्रोडक्शन सिस्टम को किसी API से हटाकर माइग्रेट करने की असल कोशिश न की हो। एंडपॉइंट URL आसान हिस्सा है। कठिन हिस्सा आपके कोडबेस की वह हर जगह है जो किसी ख़ास फ़ील्ड नाम तक पहुँचती है, किसी ख़ास एरर ढाँचे को संभालती है, या किसी ख़ास पेजिनेशन शैली को मानकर चलती है। ये मान्यताएँ बरसों में कोडबेस में ऐसी जगहों पर बिखर जाती हैं जिन्हें जाँचना किसी को याद नहीं रहता। कम्पैटिबिलिटी होस्ट उन्हें ढूँढने और ठीक करने की ज़रूरत ख़त्म कर देता है, क्योंकि ढाँचा नहीं बदलता।
इसके विपरीत, SDK एक ऐसी समस्या हल करता है जिसका सामना आप सिर्फ़ एक बार करेंगे, यानी पहली बार किसी API से जुड़ना, और इसकी क़ीमत एक ऐसी समस्या है जिसका सामना आप प्रोडक्ट के पूरे जीवनकाल में करेंगे: उस SDK के डिज़ाइन फ़ैसलों से बँधे रहना। जब SDK कोई ब्रेकिंग चेंज लाता है, तो उसे आप झेलते हैं। जब वह किसी ऐसी लैंग्वेज बाइंडिंग का रखरखाव बंद कर देता है जिस पर आप निर्भर हैं, तो वह भी आप झेलते हैं। एक सादे HTTP कम्पैटिबिलिटी होस्ट में ऐसा कुछ नहीं होता। यह बस एक URL है जो वह रिस्पॉन्स ढाँचा लौटाता है जिसे पढ़ना आप पहले से जानते हैं।
हम आम तौर पर SDK के ख़िलाफ़ नहीं हैं। एक पतला रैपर जो आपको HTTP बॉयलरप्लेट लिखने से बचाता है, एक सुविधा है, जाल नहीं, बशर्ते बाद में उसे छोड़ना प्रोवाइडर बदलने जितना बड़ा प्रोजेक्ट न हो। जाल तब है जब SDK के ढाँचे ही वे एकमात्र ढाँचे बन जाएँ जिन्हें आपका कोड समझता है, और छोड़ने का मतलब दोबारा कॉन्फ़िगर करने के बजाय दोबारा लिखना हो।
17 कम्पैटिबिलिटी होस्ट बनाना हमारे लिए एक SDK बनाने से ज़्यादा काम था। हर होस्ट को किसी दूसरे प्रोवाइडर के रिस्पॉन्स ढाँचे से, फ़ील्ड दर फ़ील्ड, बारीकी से मेल खाना होता है, ताकि मौजूदा इंटीग्रेशन को कोई अंतर पता न चले। हमने यह काम इसलिए किया क्योंकि इससे स्विच करने की लागत आपकी ओर से हमारी ओर आ जाती है। आप यह टेस्ट कर सकते हैं कि हमारा डेटा, हमारा अपटाइम और हमारा मूल्य निर्धारण आपके लिए ठीक है या नहीं, और इसके लिए पहले इंटीग्रेशन की लागत चुकाने की ज़रूरत नहीं। हर होस्ट मूल प्रोवाइडर से कैसे मेल खाता है, यह जानने के लिए कम्पैटिबिलिटी होस्ट की पूरी सूची या दस्तावेज़ देखें।
नया SDK एक डेवलपर से किसी प्रोजेक्ट के पूरे जीवनकाल के लिए किसी कंपनी के इंजीनियरिंग फ़ैसलों पर भरोसा करने को कहता है। कम्पैटिबिलिटी होस्ट इससे बहुत कम माँगता है: एक बेस URL बदलें, शायद एक API कुंजी भी, और देखें क्या होता है। यह ज़्यादा निष्पक्ष सौदा है, और यही वजह है कि हमने कुछ और बनाने से पहले कम्पैटिबिलिटी होस्ट बनाए।