प्लंबिंग के बिना Webhook डीबग करें
अंतिम अपडेट:
हर Webhook एकीकरण उसी बेग्लैमर समस्या से शुरू होता है: प्रदाता के सर्वर को आपके कोड को बुलाना होता है, आपका कोड आपके लैपटॉप पर चलता है, और कोई भी चीज़ आपके लैपटॉप तक नहीं पहुँच सकती। इसलिए असली काम—सिग्नेचर सत्यापन, पेलोड का आकार, हैंडलर लॉजिक—को डीबग करने से पहले आप पहले प्लंबिंग बनाते हैं: एक सुरंग, एक स्टेजिंग तैनाती, एक सार्वजनिक URL जो आपकी मशीन को फ़ॉरवर्ड करता है। यह लेख इस साइट के Webhook टेस्टर जैसे अस्थायी रिसीवर से उस चरण को छोड़ने के बारे में है: एक पता बनाएं, प्रदाता को उस पर इंगित करें, घटना को ट्रिगर करें, और ठीक-ठीक पढ़ें कि क्या आया। फिर दस्तावेज़ों के बजाय सच्चाई के आधार पर अपना हैंडलर लिखें।
डीबगिंग चक्र, और यह कहाँ टूटता है
स्वस्थ Webhook चक्र छोटा होता है: प्रदाता में एक घटना होती है, प्रदाता एक हस्ताक्षरित पेलोड को आपके एंडपॉइंट पर POST करता है, आपका एंडपॉइंट सिग्नेचर सत्यापित करता है, बॉडी को पार्स करता है, काम करता है और 200 जवाब देता है। अस्वस्थ चक्र—जिसे हर कोई पहचानता है—हर चरण के चारों ओर कोहरा जोड़ता है। प्रदाता का डैशबोर्ड कहता है कि डिलीवरी 500 से, या 404 से, या बिल्कुल कुछ भी नहीं कहकर विफल हुई। क्या वह आपका कोड जवाब दे रहा था, बीच का प्रॉक्सी, या टाइपो वाला एंडपॉइंट URL? पुनः प्रयास उसी घटना id के साथ आता है—या यह उसी भुगतान के लिए एक नई घटना है? दस्तावेज़ एक सुव्यवस्थित JSON उदाहरण दिखाते हैं, लेकिन उत्पादन पेलोड में अतिरिक्त फ़ील्ड, उदाहरण द्वारा चपटे किए गए नेस्टेड ऑब्जेक्ट, और कभी-कभी एक सामग्री प्रकार होता है जिसका उदाहरण ने कभी उल्लेख नहीं किया। Stripe और GitHub के Webhook दस्तावेज़ (नीचे लिंक किए गए) दोनों एक ही अनुशासनों पर ज़ोर देते हैं—सिग्नेचर सत्यापित करें, जल्दी जवाब दें, डुप्लिकेट संभालें—और जब तक आप असली डिलीवरी नहीं देख सकते, उनमें से कोई भी अभ्यास नहीं किया जा सकता।
टूटना लगभग कभी दिलचस्प लॉजिक में नहीं होता। यह उस अंतर में होता है जो आप मानते हैं कि भेजा गया और जो वास्तव में भेजा गया: एक सिग्नेचर हेडर जो उस बॉडी पर गणना किया गया जिसे आपका फ़्रेमवर्क पहले ही पार्स और पुनः सीरियलाइज़ कर चुका था, ग़लत डैशबोर्ड से कॉपी किया गया रहस्य, एक घटना प्रकार जिसे आपका switch कथन थोड़ा अलग लिखता है, एक हैंडलर जो डैशबोर्ड की परीक्षण घटना के लिए काम करता है और उत्पादन की असली घटना के लिए नहीं। यह सब आपके अपने लॉग के अंदर से अदृश्य है, क्योंकि आपके लॉग तब शुरू होते हैं जब आपका कोड अपनी पहली ग़लत धारणा पहले ही बना चुका होता है। किसी ऐसी चीज़ द्वारा रिकॉर्ड की गई कैप्चर डिलीवरी, जो आपका कोड नहीं है, वह ज़मीनी सच्चाई है जो चक्र को छोटा करती है।
एक अस्थायी रिसीवर आपको क्या देता है
एक अस्थायी रिसीवर एक सार्वजनिक URL होता है जिसका पूरा काम सब कुछ स्वीकार करना और आपको दिखाना होता है: इस साइट का Webhook टेस्टर एक क्लिक में एक बनाता है, उसे 30 मिनट तक रखता है, उनके मेथड, पाथ और क्वेरी, हेडर और बॉडी (प्रत्येक अधिकतम 256 KB) के साथ अधिकतम 50 डिलीवरी रिकॉर्ड करता है, और फिर सब कुछ अपने आप हटा देता है। यह जो देता है वह है अनुक्रम। ट्रैफ़िक देखने के लिए आधा लिखा हैंडलर सार्वजनिक मशीन पर तैनात करने—और फिर तैनाती और हैंडलर को एक साथ डीबग करने—के बजाय, आप अवलोकन को कार्यान्वयन से अलग करते हैं। पहले, कई असली घटनाओं को आते देखें और उनका वास्तविक आकार सीखें। फिर कैप्चर किए गए पेलोड के आधार पर स्थानीय रूप से हैंडलर लिखें, जिन्हें आप हाथ से अपने परीक्षणों में दोहरा सकते हैं। अंत में, प्रदाता को अपने असली एंडपॉइंट पर इंगित करें और घटना को एक बार फिर ट्रिगर करें, अब ठीक-ठीक जानते हुए कि सही डिलीवरी कैसी दिखती है और आपके हैंडलर को उसके साथ क्या करना चाहिए।
जब बातचीत टीम की सीमा पार करती है तो यह सबूत भी देता है। «आपका Webhook राशि को स्ट्रिंग के रूप में भेजता है» एक बहस है; "amount": "2000" दिखाने वाली कैप्चर डिलीवरी एक तथ्य है। वही कैप्चर प्रदाताओं के समर्थन टिकटों के सवालों का जवाब देता है—कौन सी घटना id, कौन सा टाइमस्टैम्प, कौन सा सिग्नेचर हेडर मौजूद था—लॉग पुरातत्व के एक दौर के बिना, और यह तय करता है कि गुम डिलीवरी कभी भेजी ही नहीं गई या किसी भूले हुए पुराने परीक्षण पते पर भेजी गई जिसे किसी ने अपडेट नहीं किया। पड़ोसी टूल, वही दर्शन: जब सवाल पेलोड के बजाय रीडायरेक्ट का हो, तो HTTP स्टेटस चेन ट्रेसर सर्वर के दृष्टिकोण से दिखाता है कि कोई URL क्या करता है।
वर्कफ़्लो, इस टूल के साथ
एक: Webhook टेस्टर खोलें और एक हुक बनाएं। प्राप्ति URL कॉपी करें—और इस क्षण से उस URL को एक प्रमाण की तरह समझें, जिन कारणों के लिए अगला खंड देखें। दो: उसे प्रदाता की Webhook सेटिंग में परीक्षण एंडपॉइंट के रूप में चिपकाएं—Stripe, GitHub और अधिकांश प्रदाता कई एंडपॉइंट की अनुमति देते हैं, इसलिए आपका उत्पादन एंडपॉइंट अछूता रहता है—या यदि आप अपने नियंत्रण वाले भेजने वाले को डीबग कर रहे हैं तो अपनी सेवा के कॉन्फ़िगरेशन में। तीन: घटना को ईमानदार तरीके से ट्रिगर करें। केवल डैशबोर्ड के «परीक्षण घटना भेजें» बटन के बजाय प्रदाता के असली प्रवाह (परीक्षण मोड भुगतान, एक डिस्पोज़ेबल शाखा पर असली पुश) का उपयोग करें, क्योंकि परीक्षण घटनाएँ कभी-कभी ठीक उन्हीं फ़ील्ड में असली घटनाओं से भिन्न होती हैं जिनकी आपको परवाह है। चार: कैप्चर पढ़ें। पहले मेथड और सामग्री प्रकार जांचें, फिर सिग्नेचर और घटना हेडर, फिर किसी सुंदर दिखाए गए रूप पर भरोसा करने से पहले बॉडी को कच्चे टेक्स्ट के रूप में।
पाँच: उस कैप्चर के आधार पर अपना हैंडलर लिखें या ठीक करें। ठीक जैसे प्राप्त हुई कच्ची बॉडी पर सिग्नेचर सत्यापित करें—यही कारण है कि कैप्चर अपार्स किए गए बाइट दिखाता है—और अपने हैंडलर को उस घटना id पर आइडेम्पोटेंट बनाएं जिसे आप अब पुनः प्रयासों के बीच स्थिर देख सकते हैं। छह: हुक हटाएं (या उसके 30 मिनट पूरे होने दें), प्रदाता से परीक्षण एंडपॉइंट हटाएं, और डिलीवरी को अपने असली हैंडलर पर पुनः इंगित करें। सात: घटना को एक बार फिर ट्रिगर करें और अपने एंडपॉइंट को उसका जवाब देते देखें। यदि अब यह विफल होता है, तो कैप्चर की गई अच्छी डिलीवरी और आपके हैंडलर के व्यवहार के बीच का अंतर ही पूरा बग है, और यह एक ऐसा अंतर है जिसकी आप जांच कर सकते हैं, अनुमान नहीं।
सुरक्षा: URL ही प्रमाण है
एक रिसीवर जिसे कोई भी पढ़ सके उसे लॉगिन की ज़रूरत नहीं होती, और उस सुविधा की एक कीमत है जिस पर आपको ध्यान देना चाहिए: URL में मौजूद हुक id ही एकमात्र प्रमाण है, और यह भेजने और देखने दोनों को अधिकृत करता है। जो कोई URL प्राप्त कर ले—स्क्रीनशॉट से, चैट लॉग से, साझा स्क्रीन से—वह हुक के जीवित रहने तक उसके द्वारा कैप्चर किए गए हर पेलोड को पढ़ सकता है। इसलिए नियम पासवर्ड के नियम हैं: URL को कभी सार्वजनिक रूप से पोस्ट न करें, उसे कभी लाइव उत्पादन फ़ीड के लिए उपयोग न करें, और सत्र समाप्त होने पर हुक हटाएं बजाय इसके कि कैप्चर अपना आधा घंटा पूरा करें। पेलोड दूसरी ओर से भी उसी सम्मान के पात्र हैं: एक असली भुगतान या पुश पेलोड में ग्राहक ईमेल पते, ऑर्डर विवरण और मेटाडेटा हो सकता है जिसे आप सार्वजनिक gist में नहीं चिपकाएंगे, और एक कैप्चर की गई डिलीवरी ठीक उसी श्रेणी का दस्तावेज़ है। परीक्षण मोड, डिस्पोज़ेबल रिपॉज़िटरी और सिंथेटिक घटनाएँ ठीक इसलिए मौजूद हैं ताकि डीबगिंग कलाकृतियों में चुराने लायक कुछ न हो।
टेस्टर की अपनी सीमाएँ सुरक्षा कहानी का हिस्सा हैं और टूल पेज पर स्पष्ट रूप से बताई गई हैं: कैप्चर केवल तब तक चेकर सर्वर पर संग्रहीत होते हैं जब तक हुक समाप्त न हो या आप उसे हटा न दें—अधिकतम 30 मिनट—बॉडी 256 KB तक और हुक 50 अनुरोधों तक सीमित हैं, और रिसीवर कभी कुछ लाता नहीं, किसी का पीछा नहीं करता और कुछ दोहराता नहीं, इसलिए कैप्चर किया गया पेलोड सर्वर के आउटबाउंड ट्रैफ़िक में नहीं बदल सकता। फिर भी निर्णय आपके पास रहते हैं। यदि कोई पेलोड किसी अजनबी के हाथों में समस्या होगा, तो वह साझा व्यूअर में बिल्कुल नहीं आता: उस डीबगिंग सत्र के लिए अपने बुनियादी ढांचे का उपयोग करें, जैसे आप उत्पादन रहस्यों के लिए करते। सुविधाजनक टूल अपनी जगह उस कम-संवेदनशीलता वाले काम पर कमाते हैं जो अधिकांश डीबगिंग दिनों को भरता है।
सीमाएँ: केवल प्राप्त करना और जांच करना
यह टूल जानबूझकर जो नहीं करता वह है जांच के बाद की हर चीज़। यह डिलीवरी को आपके लैपटॉप पर फ़ॉरवर्ड नहीं करता (वह सुरंग का काम है, और जब हैंडलर मौजूद हो और आप उस पर लाइव दोहरा रहे हों तो सुरंग ही सही टूल है), यह कैप्चर किए गए अनुरोध को आपके असली एंडपॉइंट पर दोहराता नहीं, यह कुछ भी बदलता या हस्ताक्षर नहीं करता, और यह 30 मिनट से अधिक का इतिहास नहीं रखता। ये अनुपस्थितियाँ ही डिज़ाइन हैं: फ़ॉरवर्ड करने वाला रिसीवर एक प्रॉक्सी है जिससे आपका ट्रैफ़िक बहता है, दोहराने वाला रिसीवर एक भेजने वाला है, और दोनों 30-मिनट के इनबॉक्स से बड़े भरोसे हैं। टेस्टर का उपयोग उस चरण के लिए करें जिसके लिए यह उपयुक्त है—हैंडलर बनाने से पहले और बनाते समय सच्चाई देखना—और जैसे ही एकीकरण लाइव हो, अपने प्रमाणीकरण और लॉगिंग के पीछे अपने एंडपॉइंट को कार्यभार संभालने दें।