Webhook สำหรับซอฟต์แวร์ให้เช่า: การเชื่อมต่อแบบเรียลไทม์ช่วยให้ระบบซิงค์กันได้อย่างไร

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

ส่วนใหญ่แล้วไม่มีอะไรเปลี่ยนแปลงเลย คุณส่งคำขอออกไป ได้ผลลัพธ์ที่หน้าตาเหมือนเดิมทุกประการกลับมา แล้วก็ทิ้งมันไป ทำแบบนี้ซ้ำทุกห้านาที วันละ 288 ครั้ง สำหรับทุกบัญชีที่คุณซิงค์ข้อมูลอยู่ นั่นหมายความว่าคุณกำลังเสียการเรียก API การคิวรีฐานข้อมูล และรอบการประมวลผล เพียงเพื่อรู้ในเกือบทุกครั้งว่าไม่มีอะไรเกิดขึ้นเลย

ที่แย่กว่านั้นคือ polling นั้นช้าโดยธรรมชาติของการออกแบบ ถ้าคุณ poll ทุกห้านาที ความล่าช้าที่ดีที่สุดระหว่างการเกิดเหตุการณ์กับการที่ระบบของคุณรู้เรื่องนั้นจะใกล้เคียงศูนย์ และกรณีที่แย่ที่สุดจะอยู่ที่เกือบห้านาที การ poll ให้ถี่น้อยลงเพื่อประหยัดทรัพยากรจะยิ่งทำให้กรณีที่แย่ที่สุดนั้นแย่ลงไปอีก ไม่มีทางที่จะได้ทั้งประสิทธิภาพและความรวดเร็วพร้อมกันด้วย polling คุณต้องแลกอย่างใดอย่างหนึ่งอยู่เสมอ

webhook พลิกความสัมพันธ์นี้กลับด้าน แทนที่ระบบของคุณจะถามซ้ำๆ ว่ามีอะไรเปลี่ยนแปลงหรือไม่ ระบบให้เช่าจะแจ้งคุณทันทีที่มีบางอย่างเกิดขึ้นจริง คุณเลิกจ่ายต้นทุนของการถาม และเริ่มจ่ายเฉพาะสำหรับช่วงเวลาที่สำคัญจริงๆ เท่านั้น

webhook คือคำขอ HTTP ธรรมดา ซึ่งมักเป็น POST ที่ระบบหนึ่งส่งไปยังอีกระบบหนึ่งโดยอัตโนมัติเมื่อเกิดเหตุการณ์เฉพาะเจาะจงขึ้น แทนที่จะเป็นคำขอที่คุณส่งเองเมื่อรู้สึกอยากตรวจสอบ คุณลงทะเบียน URL ซึ่งก็คือ endpoint บนเซิร์ฟเวอร์ของคุณเอง ไว้กับระบบที่คุณต้องการรับข้อมูลด้วย และเมื่อเหตุการณ์ที่เกี่ยวข้องเกิดขึ้นในฝั่งของพวกเขา ระบบนั้นจะส่งคำขอไปยัง URL นั้นพร้อมข้อมูลว่าเกิดอะไรขึ้น

นี่คือความแตกต่างหลักจากการเรียก API ทั่วไป คำขอ API ปกติทำงานแบบ pull คุณเป็นผู้ตัดสินใจว่าจะถามเมื่อไหร่ และระบบจะตอบก็ต่อเมื่อถูกถามเท่านั้น ส่วน webhook ทำงานแบบ push ระบบเป็นผู้ตัดสินใจว่าจะแจ้งคุณเมื่อไหร่ โดยอิงจากเหตุการณ์ของระบบเอง ไม่ใช่ตามตารางเวลาของคุณ คำขอเกิดขึ้นจากเหตุการณ์ ไม่ใช่จากไคลเอนต์ที่ต้องการรู้อะไรบางอย่างในขณะนั้น

ในทางปฏิบัติ สิ่งนี้เปลี่ยนรูปแบบโค้ดการเชื่อมต่อของคุณไปโดยสิ้นเชิง แทนที่จะเป็นลูปที่คอยดึงข้อมูลมาเทียบความแตกต่าง คุณจะเขียนตัวจัดการเล็กๆ ที่รับคำขอเข้ามา ตรวจสอบว่ามันมาจากระบบที่คาดไว้จริงหรือไม่ แล้วตอบสนองตามเหตุการณ์ที่ระบุไว้ ตัวอย่างเช่น Renttix เปิดให้ใช้ webhook endpoint เป็นส่วนหนึ่งของ API สำหรับนักพัฒนา เพื่อให้ธุรกิจสามารถลงทะเบียน URL และได้รับการแจ้งเตือนแทนที่จะต้องคอยถามซ้ำๆ

ความไม่มีประสิทธิภาพของ polling จะยิ่งแย่ลง ไม่ใช่ดีขึ้น เมื่อธุรกิจให้เช่าเติบโตขึ้น คลังสินค้าแห่งเดียวที่ซิงค์คำสั่งซื้อจำนวนไม่มากกับเครื่องมือภายนอกหนึ่งตัวอาจรอดพ้นไปได้ด้วยการ poll ทุกๆ สองสามนาทีโดยไม่มีใครสังเกตเห็นความสิ้นเปลือง แต่เมื่อเพิ่มคลังสินค้ามากขึ้น การเชื่อมต่อมากขึ้น และระบบภายนอกมากขึ้นที่แต่ละระบบต้องรู้เกี่ยวกับกิจกรรมคำสั่งซื้อและการชำระเงิน จำนวนคำขอตรวจสอบความเปลี่ยนแปลงก็จะเพิ่มขึ้นอย่างรวดเร็ว โดยส่วนใหญ่ยังคงได้รับคำตอบว่าไม่มีอะไรเปลี่ยนแปลง

ยังมีเพดานในทางปฏิบัติอีกด้วย API มักมีการจำกัดอัตราด้วยเหตุผลที่ดี และกลยุทธ์ polling ที่ก้าวร้าวพอที่จะรู้สึกใกล้เคียงเรียลไทม์มักจะชนกับข้อจำกัดเหล่านั้นก่อนที่จะให้ผลลัพธ์ที่ใกล้เคียงเรียลไทม์จริงๆ เสียอีก สุดท้ายคุณก็ต้องปรับความถี่ของ polling เป็นการประนีประนอมระหว่างภาระของเซิร์ฟเวอร์ ข้อจำกัดอัตรา และระดับความล้าสมัยของข้อมูลที่ยอมรับได้ และไม่มีข้อแลกเปลี่ยนใดในนี้ที่จะง่ายขึ้นตามกาลเวลา

webhook หลีกเลี่ยงข้อแลกเปลี่ยนทั้งหมดนี้ได้ ปริมาณการแจ้งเตือนที่คุณได้รับจะแปรผันตามจำนวนสิ่งที่เกิดขึ้นจริง ไม่ใช่ตามความถี่ที่คุณรู้สึกว่าต้องถาม สัปดาห์ที่เงียบสงบแทบไม่สร้าง traffic ของ webhook เลย ส่วนสัปดาห์ที่ยุ่งก็จะสร้างการแจ้งเตือนพอดีเท่ากับจำนวนเหตุการณ์ที่เกิดขึ้น ไม่มากไปกว่านั้น

คุณค่าของ webhook ไม่ได้อยู่ที่กลไกของมันเอง แต่อยู่ที่สิ่งที่กลายเป็นไปได้จริงเมื่อคุณมีมัน โดยทั่วไปแล้ว ระบบให้เช่าสามารถใช้ webhook เพื่อแจ้งให้ระบบภายนอกทราบทันทีที่มีการเปลี่ยนแปลง เช่น เมื่อสถานะคำสั่งซื้อเปลี่ยนไป มีการเรียกเก็บเงิน หรือการคืนสินค้าถูกทำเครื่องหมายว่าเสร็จสมบูรณ์ สิ่งที่สำคัญสำหรับผู้สร้างการเชื่อมต่อคือ การแจ้งเตือนมาถึงใกล้กับช่วงเวลาที่เหตุการณ์เกิดขึ้นจริง แทนที่จะมาถึงหลังจากช่วงเวลา polling ที่อาจยาวนาน

ยกตัวอย่างเพื่อประกอบความเข้าใจ ลองนึกถึงธุรกิจให้เช่าแห่งหนึ่งที่สร้างแดชบอร์ดภายในของตัวเองสำหรับทีมปฏิบัติการ เป็นหน้าจอขนาดใหญ่ที่แสดงว่าอะไรกำลังถูกเช่าอยู่ อะไรที่ต้องคืน และอะไรที่ชำระเงินแล้ว หากไม่มี webhook การทำให้แดชบอร์ดนี้ทันสมัยอยู่เสมอหมายถึงการยิงคำขอไปที่ API ทุกๆ สองนาที ซึ่งส่วนใหญ่แล้วก็ไม่มีอะไรใหม่ แต่เมื่อมี webhook แล้ว แบ็กเอนด์ของแดชบอร์ดก็แค่คอยฟังเหตุการณ์ที่เกี่ยวข้อง แล้วอัปเดตข้อมูลที่เกี่ยวข้องทันทีที่การแจ้งเตือนมาถึง หน้าจอจะยังคงถูกต้องแม่นยำโดยไม่ต้องถามซ้ำตลอดเวลา

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

webhook นำมาซึ่งรูปแบบความล้มเหลวใหม่ที่ polling ไม่มี นั่นคือการแจ้งเตือนอาจส่งไม่สำเร็จ และไม่จำเป็นว่าทั้งสองฝ่ายจะรู้ตัวทันที endpoint ของคุณอาจล่มไปหนึ่งนาทีระหว่างการ deploy ปัญหาเครือข่ายอาจทำให้คำขอหายไป โค้ดของคุณเองอาจโยนข้อผิดพลาดขึ้นมาระหว่างการประมวลผล payload หากคุณมองไม่เห็นสิ่งเหล่านี้เลย คุณก็จะต้องดีบักแบบมองไม่เห็น เดาว่าระบบให้เช่าพยายามแจ้งคุณหรือไม่ และเดาว่ามันส่งอะไรมา

ตรงนี้แหละที่ delivery log แสดงคุณค่าของมัน บันทึกการส่ง webhook ช่วยให้นักพัฒนามองย้อนกลับไปเห็นได้ว่าจริงๆ แล้วส่งอะไรออกไปและได้รับหรือไม่ แทนที่จะต้องอาศัยการอนุมานจากอาการปลายทาง เช่น แดชบอร์ดที่เงียบๆ หยุดอัปเดตไปเฉยๆ API สำหรับนักพัฒนา ของ Renttix มี delivery log รวมอยู่ด้วยด้วยเหตุผลนี้เอง เมื่อการเชื่อมต่อทำงานผิดปกติ คำถามแรกที่มีประโยชน์ที่สุดมักจะเป็นว่า webhook ถูกส่งหรือไม่ และมีเนื้อหาอะไรอยู่ในนั้น และ delivery log ก็ตอบคำถามนั้นได้โดยตรง แทนที่จะปล่อยให้คุณต้องมานั่งปะติดปะต่อจาก log ของแอปพลิเคชันตัวเอง

การบันทึก request (request logging) ก็สำคัญด้วยเหตุผลเดียวกันในฝั่งการเรียก API ของการเชื่อมต่อ ไม่ใช่แค่ฝั่ง webhook เท่านั้น ระหว่าง delivery log สำหรับการแจ้งเตือนขาออก กับการบันทึก request สำหรับการเรียก API ขาเข้า นักพัฒนาที่สร้างระบบบน API ของ Renttix จะมองเห็นทั้งสองทิศทางของการเชื่อมต่อ แทนที่จะเห็นได้แค่ครึ่งเดียวของตัวเอง

webhook ดูแลส่วนที่ว่า บอกฉันทีเมื่อมีอะไรเกิดขึ้น ของการเชื่อมต่อ แต่การเชื่อมต่อจริงส่วนใหญ่ก็ยังต้องเรียก API โดยตรงด้วย เพื่อดึงรายละเอียดเพิ่มเติม ค้นหาบางสิ่ง หรือเขียนข้อมูลกลับไป นั่นหมายความว่าต้องมี API key และ API key ก็สมควรได้รับความใส่ใจเช่นเดียวกับการออกแบบ webhook ที่อยู่รอบๆ มัน

การจำกัดขอบเขต (scoping) มีความสำคัญเพราะการเชื่อมต่อควรทำได้เฉพาะสิ่งที่มันต้องการจริงๆ เท่านั้น key ที่สร้างขึ้นสำหรับการเชื่อมต่อรายงานแบบอ่านอย่างเดียวไม่ควรสามารถแก้ไขคำสั่งซื้อได้ด้วย key ที่ใช้โดยเครื่องมือด้านการเงินซึ่งต้องการแค่ข้อมูลการชำระเงินไม่ควรเข้าถึงส่วนที่เหลือของบัญชีได้ key ที่จำกัดขอบเขตหมายความว่า หากการเชื่อมต่อหนึ่งถูกบุกรุก ความเสียหายจะจำกัดอยู่แค่สิ่งที่ key นั้นได้รับอนุญาตให้แตะต้อง ไม่ใช่ทั้งบัญชี

ความสามารถในการเพิกถอน (revocability) มีความสำคัญในช่วงเวลาที่มีอะไรผิดพลาด หรือเพียงแค่ตอนที่การเชื่อมต่อถูกเลิกใช้งาน key ที่สามารถเพิกถอนได้ทันที โดยไม่กระทบต่อการเข้าถึงของการเชื่อมต่ออื่นใด หมายความว่า key ที่ถูกบุกรุกหรือล้าสมัยจะหยุดทำงานทันทีที่คุณตัดสินใจ แทนที่จะคงอยู่เป็นความเสี่ยงถาวรเพราะการหมุนเวียน (rotate) มันจะทำให้สิ่งอื่นอีกสามอย่างพังไปด้วย API สำหรับนักพัฒนา ของ Renttix ออก key ที่ทั้งจำกัดขอบเขตและเพิกถอนได้ด้วยเหตุผลนี้เอง webhook และ key คือสองส่วนของการออกแบบการเชื่อมต่อที่ปลอดภัยชุดเดียวกัน ไม่ใช่เรื่องที่แยกจากกัน

มีรูปแบบเก่าอยู่แบบหนึ่งที่สิ่งนี้เข้ามาแทนที่ นั่นคือการส่งออกข้อมูลจากระบบให้เช่าเป็นระยะๆ เช่น ไฟล์ CSV รายงานตามกำหนดเวลา หรือการดาวน์โหลดด้วยมือ แล้วนำสิ่งที่คุณต้องการจริงๆ มาสร้างขึ้นใหม่จากภาพนิ่งนั้น วิธีนี้ใช้งานได้ แต่มันจะล้าสมัยไปแล้วตั้งแต่วินาทีที่ถูกสร้างขึ้น และมันเปลี่ยนทุกการเชื่อมต่อให้กลายเป็นโปรเจกต์ data engineering ขนาดเล็ก

REST API ที่มีเอกสารประกอบเปลี่ยนความสัมพันธ์นี้ Renttix เปิดให้ใช้ REST API ที่มีเอกสารประกอบภายใต้ /api/v1 ซึ่งหมายความว่าการเชื่อมต่อถูกสร้างขึ้นบนอินเทอร์เฟซที่มั่นคงและมีคำอธิบาย แทนที่จะสร้างบนรูปแบบใดก็ตามที่การส่งออกแบบครั้งเดียวบังเอิญมี เมื่อรวมกับ webhook สำหรับการแจ้งเตือนแบบเรียลไทม์ และ delivery log บวกกับ request logging เพื่อให้มองเห็นได้ทั้งสองทิศทางของ traffic ส่วนประกอบต่างๆ ก็พร้อมสำหรับการสร้างสิ่งที่ใกล้เคียงกับการเชื่อมต่อแบบสดระหว่างระบบมากกว่าการทิ้งข้อมูลเป็นระยะๆ

ไม่มีสิ่งใดในนี้ที่ต้องใช้ความพยายามทางวิศวกรรมมากมายเพื่อให้ได้คุณค่าจากมัน webhook endpoint เดียวที่ตอบสนองต่อเหตุการณ์ประเภทหนึ่ง หนุนหลังด้วย key ที่จำกัดขอบเขตซึ่งทำได้แค่สิ่งที่การเชื่อมต่อนั้นต้องการ ก็ถือว่าอยู่ในตำแหน่งที่ดีกว่าลูป polling หรือการส่งออกตอนกลางคืนไปมากแล้ว และนี่คือรูปแบบที่คุณสามารถขยายทีละการเชื่อมต่อได้ตามความต้องการที่เพิ่มขึ้น

จุดเริ่มต้นในทางปฏิบัตินั้นเล็กมาก เลือกข้อมูลชิ้นเดียวที่ระบบปลายทางต้องการรู้แบบเรียลไทม์จริงๆ ลงทะเบียน webhook endpoint สำหรับมัน แล้วสร้าง API key ที่จำกัดขอบเขตเฉพาะสิ่งที่การเชื่อมต่อนั้นแตะต้อง คอยดู delivery log ระหว่างที่คุณทดสอบ เพื่อให้คุณเห็นว่าจริงๆ แล้วมีอะไรถูกส่งออกไปบ้าง แทนที่จะเดาเอา

จากจุดนั้น รูปแบบนี้จะขยายตัวไปเองตามธรรมชาติ มีเหตุการณ์มากขึ้น มีการเชื่อมต่อมากขึ้น แต่ละอันมี key ที่จำกัดขอบเขตของตัวเอง โดยไม่ต้องย้อนกลับไปที่ลูปที่ถามคำถามเดิมทุกๆ สองสามนาทีอีกเลย หากคุณกำลังพิจารณาว่า webhook และ API จะเข้ากับระบบของคุณเองได้อย่างไร ลองพูดคุยกับทีมงานเกี่ยวกับสิ่งที่คุณต้องการเชื่อมต่อดู