รีเพลย์ Webhook: ดีบักโดยไม่ต้องทริกเกอร์ใหม่

การรีเพลย์ Webhook จะส่งคอลแบ็ก HTTP ที่จับไว้ก่อนหน้านี้กลับไปยัง handler บนเครื่องโลคัลของคุณ โดยไม่ต้องขอให้ผู้ให้บริการต้นทางส่งเหตุการณ์ใหม่ แทนที่จะทริกเกอร์การชำระเงิน Stripe, push ของ GitHub หรือข้อความ Twilio ใหม่ คุณรีเพลย์คำขอเดิมเป๊ะ ทั้ง header, body และทุกอย่าง จากประวัติคำขอของคุณ

ทำไมการรีเพลย์ Webhook จึงสำคัญ

การดีบัก Webhook มักวนอยู่ในลูปที่น่าเบื่อ: ทริกเกอร์เหตุการณ์ ตรวจการส่ง หาบั๊ก แก้โค้ด แล้วทริกเกอร์ใหม่ การทริกเกอร์เหตุการณ์ต้นทางใหม่นั้นช้า สร้างความวุ่นวาย และบางครั้งทำไม่ได้ (เหตุการณ์ชำระเงินครั้งเดียว ทรัพยากรที่ถูกลบ หรือ API ทดสอบที่จำกัดอัตรา)

การรีเพลย์ย่นลูปนั้นลง จับครั้งเดียว แก้ handler แล้วรีเพลย์ payload เดิมจนกว่าจะผ่าน โดยไม่แตะผู้ให้บริการภายนอกเลย

การรีเพลย์ Webhook ทำงานอย่างไร

1. คอลแบ็กมาถึง URL ทันเนลของคุณและถูกส่งต่อไปยังแอปบนเครื่องโลคัล
2. เครื่องมือทันเนลจับคำขอทั้งหมด: เมธอด, path, header และ body
3. คุณแก้โค้ด handler ตามสิ่งที่เห็นในคำขอที่จับไว้
4. คุณรีเพลย์คำขอที่จับไว้ไปยัง endpoint บนเครื่องโลคัลด้วยการกระทำเดียว
5. ทำซ้ำจนกว่า handler จะคืนค่าตอบกลับที่ถูกต้อง

เวิร์กโฟลว์นี้ต้องใช้ ทันเนล localhost ที่มีการจับคำขอในตัว ไม่ใช่แค่ส่งต่อทราฟฟิก

กรณีใช้งานการรีเพลย์ Webhook

การพัฒนา handler

สร้างและทดสอบ handler ของ Webhook แบบวนซ้ำ รีเพลย์เหตุการณ์ checkout.session.completed ของ Stripe สิบครั้งขณะปรับตรรกะการ parse

การทดสอบ idempotency

ผู้ให้บริการส่งเหตุการณ์ซ้ำระหว่างการลองใหม่ รีเพลย์ payload เดิมหลายครั้งเพื่อยืนยันว่า handler ประมวลผลรายการซ้ำได้อย่างปลอดภัย โดยไม่เกิดการเรียกเก็บซ้ำหรือเรคคอร์ดซ้ำ

การดีบักการตรวจสอบลายเซ็น

เมื่อการตรวจลายเซ็นล้มเหลว ให้รีเพลย์คำขอเดิมพร้อม header ที่ไม่ถูกแตะต้อง เพื่อแยกแยะว่าปัญหาอยู่ที่ตรรกะการตรวจสอบหรือการ parse payload

การทดสอบ regression

บันทึกคำขอที่จับไว้จากเหตุการณ์ทดสอบที่ใกล้เคียงโปรดักชัน แล้วรีเพลย์หลังการรีแฟกเตอร์เพื่อจับการเปลี่ยนแปลงที่ทำให้พังก่อนดีพลอย

รีเพลย์ Webhook ด้วย PortPreview

1. เริ่มแอปแล้วรัน npx portpreview 3000
2. ตั้งค่าผู้ให้บริการให้ส่งคอลแบ็กไปยัง URL ทันเนล
3. ทริกเกอร์เหตุการณ์ทดสอบและตรวจคำขอที่จับไว้ใน PortPreview
4. แก้ handler แล้วรีเพลย์คำขอที่จับไว้
5. ตรวจสถานะและ body ของการตอบกลับโดยไม่ต้องทริกเกอร์ผู้ให้บริการใหม่

PortPreview รักษา header เดิมไว้ การตรวจสอบลายเซ็นของผู้ให้บริการจึงยังมีความหมายระหว่างการรีเพลย์

รีเพลย์ กับ ทริกเกอร์ใหม่: ใช้อันไหนเมื่อไร

• รีเพลย์: บั๊กตรรกะ handler, การ parse payload, การตรวจ idempotency, การดีบักลายเซ็น
• ทริกเกอร์ใหม่: ทดสอบการสร้างเหตุการณ์ฝั่งผู้ให้บริการ ยืนยันการลงทะเบียน Webhook หรือการ integration แบบ end-to-end กับสถานะจริงของผู้ให้บริการ

สำหรับการตั้งค่าเฉพาะผู้ให้บริการ ดูคู่มือเรื่อง การทดสอบ Webhook Stripe บนเครื่องโลคัล, การทดสอบ Webhook GitHub บนเครื่องโลคัล และ การทดสอบ Webhook Twilio บนเครื่องโลคัล

แนวปฏิบัติที่ดีสำหรับการรีเพลย์ Webhook

• ตรวจสอบลายเซ็นเสมอระหว่างการรีเพลย์ ไม่ใช่แค่ตอนส่งครั้งแรก
• ทดสอบการส่งซ้ำโดยรีเพลย์เหตุการณ์เดิมหลายครั้ง
• เก็บประวัติคำขอไว้ระหว่าง branch ฟีเจอร์เพื่อการตรวจ regression
• ใช้ข้อมูลรับรองโหมดทดสอบ เพื่อให้เหตุการณ์ที่รีเพลย์ไม่กระทบข้อมูลโปรดักชัน

เข้าร่วม waitlist ของ PortPreview เพื่อให้การจับและรีเพลย์ Webhook ฝังอยู่ในเวิร์กโฟลว์ทันเนลของคุณ