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