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