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