वेबहुक रीप्ले पहले कैप्चर किए गए HTTP कॉलबैक को आपके लोकल हैंडलर पर फिर से भेजता है, बिना अपस्ट्रीम प्रोवाइडर से इवेंट दोबारा डिलीवर कराए। Stripe चार्ज, GitHub पुश या Twilio संदेश को दोबारा ट्रिगर करने के बजाय, आप अपनी रिक्वेस्ट हिस्ट्री से वही सटीक रिक्वेस्ट — हेडर, बॉडी और सब कुछ — रीप्ले करते हैं।
वेबहुक रीप्ले क्यों ज़रूरी है
वेबहुक डिबगिंग आमतौर पर एक थकाऊ लूप में चलती है: इवेंट ट्रिगर करें, डिलीवरी जाँचें, बग खोजें, कोड ठीक करें, फिर ट्रिगर करें। अपस्ट्रीम इवेंट दोबारा ट्रिगर करना धीमा, शोरगुल भरा और कभी-कभी असंभव होता है (एक-बार के पेमेंट इवेंट, हटाए गए रिसोर्स, या रेट-लिमिटेड टेस्ट API)।
रीप्ले उस लूप को छोटा कर देता है। एक बार कैप्चर करें, हैंडलर ठीक करें, और जब तक पास न हो तब तक वही पेलोड रीप्ले करें — बाहरी प्रोवाइडर को छुए बिना।
वेबहुक रीप्ले कैसे काम करता है
- एक कॉलबैक आपकी टनल URL पर आता है और आपके लोकल ऐप पर फ़ॉरवर्ड होता है।
- टनल टूल पूरी रिक्वेस्ट कैप्चर करता है: मेथड, पाथ, हेडर और बॉडी।
- कैप्चर की गई रिक्वेस्ट में जो दिखता है, उसके आधार पर आप हैंडलर कोड ठीक करते हैं।
- आप एक ही क्रिया से कैप्चर की गई रिक्वेस्ट को अपने लोकल एंडपॉइंट पर रीप्ले करते हैं।
- जब तक हैंडलर सही रिस्पॉन्स न दे, तब तक दोहराएँ।
इस वर्कफ़्लो के लिए सिर्फ़ ट्रैफ़िक फ़ॉरवर्डिंग नहीं, बल्कि अंतर्निर्मित रिक्वेस्ट कैप्चर वाला localhost टनल चाहिए।
वेबहुक रीप्ले के उपयोग
हैंडलर डेवलपमेंट
वेबहुक हैंडलर को क्रमिक रूप से बनाएँ और टेस्ट करें। पार्सिंग लॉजिक को निखारते हुए वही Stripe checkout.session.completed इवेंट दस बार रीप्ले करें।
आइडम्पोटेंसी टेस्टिंग
प्रोवाइडर रीट्राई के दौरान डुप्लिकेट इवेंट डिलीवर करते हैं। यह पुष्टि करने के लिए कि आपका हैंडलर डुप्लिकेट को सुरक्षित रूप से संभालता है — दोहरे चार्ज या डुप्लिकेट रिकॉर्ड के बिना — वही पेलोड कई बार रीप्ले करें।
सिग्नेचर वेरिफिकेशन डिबगिंग
जब सिग्नेचर जाँच विफल हो, तो यह पता लगाने के लिए कि समस्या वेरिफिकेशन लॉजिक में है या पेलोड पार्सिंग में, मूल रिक्वेस्ट को बरकरार हेडर के साथ रीप्ले करें।
रिग्रेशन टेस्टिंग
प्रोडक्शन-जैसे टेस्ट इवेंट से कैप्चर की गई रिक्वेस्ट सहेजें और रिफैक्टर के बाद उन्हें रीप्ले करें ताकि डिप्लॉय से पहले ब्रेकिंग बदलाव पकड़े जा सकें।
PortPreview के साथ वेबहुक रीप्ले
- अपना ऐप शुरू करें और
npx portpreview 3000चलाएँ। - अपने प्रोवाइडर को टनल URL पर कॉलबैक भेजने के लिए कॉन्फ़िगर करें।
- एक टेस्ट इवेंट ट्रिगर करें और PortPreview में कैप्चर की गई रिक्वेस्ट जाँचें।
- अपना हैंडलर ठीक करें, फिर कैप्चर की गई रिक्वेस्ट रीप्ले करें।
- प्रोवाइडर को दोबारा ट्रिगर किए बिना रिस्पॉन्स स्टेटस और बॉडी सत्यापित करें।
PortPreview मूल हेडर सुरक्षित रखता है, इसलिए रीप्ले के दौरान भी प्रोवाइडर का सिग्नेचर वेरिफिकेशन सार्थक बना रहता है।
रीप्ले बनाम दोबारा ट्रिगर: कब क्या इस्तेमाल करें
- रीप्ले: हैंडलर लॉजिक बग, पेलोड पार्सिंग, आइडम्पोटेंसी जाँच, सिग्नेचर डिबगिंग।
- दोबारा ट्रिगर: प्रोवाइडर-साइड इवेंट जनरेशन की टेस्टिंग, वेबहुक रजिस्ट्रेशन सत्यापित करना, या लाइव प्रोवाइडर स्थिति के साथ एंड-टू-एंड इंटीग्रेशन।
प्रोवाइडर-विशिष्ट सेटअप के लिए, Stripe वेबहुक लोकल टेस्टिंग, GitHub वेबहुक लोकल टेस्टिंग और Twilio वेबहुक लोकल टेस्टिंग की गाइड देखें।
वेबहुक रीप्ले की सर्वोत्तम प्रथाएँ
- सिर्फ़ पहली डिलीवरी पर नहीं, रीप्ले के दौरान भी हमेशा सिग्नेचर सत्यापित करें।
- वही इवेंट कई बार रीप्ले करके डुप्लिकेट डिलीवरी टेस्ट करें।
- रिग्रेशन जाँच के लिए फ़ीचर ब्रांच के दौरान रिक्वेस्ट हिस्ट्री बनाए रखें।
- टेस्ट-मोड क्रेडेंशियल इस्तेमाल करें ताकि रीप्ले किए गए इवेंट कभी प्रोडक्शन डेटा को प्रभावित न करें।
वेबहुक कैप्चर और रीप्ले को अपने टनल वर्कफ़्लो में अंतर्निर्मित पाने के लिए PortPreview की वेटलिस्ट में शामिल हों।