เมื่อเราสร้างแอปพลิเคชันบนเว็บ มักจะมีการให้บริการหลายอย่าง ในกรณีส่วนใหญ่ พวกมันประกอบด้วยการให้บริการเว็บที่แตกต่างกันหลายอย่างทำงานร่วมกัน ในแอปพลิเคชันบนเว็บประเภทนี้ที่ประกอบด้วยหลายบริการ วิธีการถ่ายโอนข้อมูลเป็นสิ่งที่นักพัฒนาทุกคนต้องพิจารณา เมื่อพูดถึงการแก้ปัญหานี้ สองวิธีการที่กลายเป็นพื้นฐานคือ webhook และ polling แต่ละวิธีให้วิธีที่ไม่ซ้ำกันในการดึงและส่งข้อมูลจากบริการหนึ่งไปยังอีกบริการ การเลือกหนึ่งในสองนี้สามารถมีผลกระทบอย่างมากต่อประสิทธิภาพความสามารถในการทำงานเรียลไทม์ และประสบการณ์การใช้งานโดยรวมของแอปพลิเคชันคุณ บทความนี้จะเปรียบเทียบ webhook กับ polling วิเคราะห์ข้อดีและข้อเสียของแต่ละวิธี และอธิบายว่าเมื่อใดควรใช้วิธีใด ## Polling คืออะไร? Polling (มักจะเรียกว่า API polling) เป็นกระบวนการที่ลูกค้าขอข้อมูลเฉพาะที่ช่วงเวลากำหนด (เช่นทุก x วินาที) และเซิร์ฟเวอร์ตอบกลับด้วยข้อมูลที่ร้องขอ คิดว่ามันเป็นการถามว่า “มีข้อมูลใหม่ไหม?” ที่ช่วงเวลาที่กำหนด การดึงข้อมูลแบบ polling สามารถใช้งานผ่านการส่งคำขอ HTTP ที่ลูกค้าส่งคำขอ GET ไปยังเซิร์ฟเวอร์และเซิร์ฟเวอร์ตอบกลับด้วยข้อมูลที่ร้องขอ ลองจินตนาการว่าจอห์นสร้างผลิตภัณฑ์เอกสาร AI ชื่อว่า Doc.AI และใช้ Logto สำหรับการจัดการตัวตนของผู้ใช้ แฟรงค์เป็นผู้ใช้ที่ลงทะเบียนกับผลิตภัณฑ์ของจอห์นและสร้างบัญชีส่วนตัวของเขาเอง วันหนึ่งแฟรงค์เข้าร่วมพื้นที่ทำงานที่สร้างโดยเพื่อนของเขา เดวิด ในขณะนั้นจอห์นต้องการส่งอีเมลถึงแฟรงค์เพื่อขอให้เขาเปิดใช้งานการตรวจสอบตัวตนแบบหลายปัจจัย (MFA) เพื่อเสริมความปลอดภัยให้กับบัญชีของเขาก่อนที่จอห์นจะให้สิทธิ์เขาในการเข้าถึงทรัพยากรที่มีความละเอียดมากขึ้น ระบบหลังบ้านของจอห์นจำเป็นต้องทำ polling ไปยัง API ที่เกี่ยวข้องเพื่อทราบว่าแฟรงค์เข้าร่วมพื้นที่ทำงานของเดวิดหรือไม่ ```mermaid sequenceDiagram participant Client as Doc.AI (server) participant Server as Logto loop Polling every x seconds Client->>Server: Send API request
"แฟรงค์เข้าร่วมพื้นที่ทำงานของเดวิดหรือไม่?" Server-->>Client: ไม่มี end note right of Client: แฟรงค์เข้าร่วมพื้นที่ทำงานของเดวิด Client->>Server: Send API request
"แฟรงค์เข้าร่วมพื้นที่ทำงานของเดวิดหรือไม่?" Server-->>Client: ใช่แล้ว! note right of Client: Doc.AI เริ่มการทำงาน:
1. ส่งอีเมลถึงแฟรงค์
2. รอ MFA เสร็จสิ้น
... ``` ## Webhook คืออะไร? Webhook (หรือ "HTTP callback") เป็นกลไกในการสื่อสารข้อมูลแบบเรียลไทม์ที่เซิร์ฟเวอร์จะส่งข้อมูลไปยังลูกค้าเมื่อมีเหตุการณ์เกิดขึ้น แทนที่จะเป็นการที่ลูกค้าขอข้อมูล webhook จะผลักดันข้อมูลออกไปยังลูกค้าทุกครั้งที่มีการอัปเดต คิดว่ามันเป็นกล่องจดหมายสำหรับแอปพลิเคชันของคุณ เมื่อเกิดเหตุการณ์บางอย่าง เช่น การสมัครเป็นสมาชิกใหม่หรือมีการชำระเงิน webhook จะส่งข้อความไปยังกล่องจดหมายเพื่อให้แอปพลิเคชันของคุณรู้ว่าเกิดอะไรขึ้น เรามาต่อกันด้วยตัวอย่าง Doc.AI ของเราที่เราใช้ในการอธิบาย polling นี่คือวิธีที่โครงร่างลำดับของเหตุการณ์จะดูเหมือนถ้าเราใช้ webhook เพื่อตรวจสอบว่าแฟรงค์เข้าร่วมพื้นที่ทำงานของเดวิดหรือไม่: ```mermaid sequenceDiagram participant Client as Doc.AI (server) participant Server as Logto note right of Client: คำขอ HTTP อื่น ๆ ... note right of Client: ... note right of Client: แฟรงค์เข้าร่วมพื้นที่ทำงานของเดวิด Server->>Client: Webhook ถูกทริกเกอร์ตามเหตุการณ์
"แฟรงค์เข้าร่วมพื้นที่ทำงานของเดวิด" note right of Client: Doc.AI เริ่มการทำงาน:
1. ส่งอีเมลถึงแฟรงค์
2. รอ MFA เสร็จสิ้น
... ``` ## ความแตกต่างที่สำคัญ - ต้นทางของคำขอ Polling จะเริ่มโดยลูกค้า (ในตัวอย่างของเรา Doc.AI คือคลายเอ็นต์และ Logto คือเซิร์ฟเวอร์) และ webhook จะถูกทริกเกอร์โดยเหตุการณ์และเริ่มโดยเซิร์ฟเวอร์ - การใช้ทรัพยากร Polling ใช้ทรัพยากรคอมพิวเตอร์เพราะส่งคำขอไปยังเซิร์ฟเวอร์เป็นระยะ ๆ ส่งผลให้เกิดการใช้ทรัพยากรคอมพิวเตอร์อย่างไม่มีประสิทธิภาพ แต่ในขณะที่ webhook ถูกเริ่มโดยเซิร์ฟเวอร์ "ตามต้องการ" เปรียบเทียบกับ polling แล้วทั้งลูกค้าและเซิร์ฟเวอร์จะใช้งานทรัพยากรน้อยลงมาก - เวลา Polling ถูกเริ่มโดยลูกค้า ดังนั้นลูกค้าสามารถควบคุมเวลาที่ได้ข้อมูลได้ อย่างไรก็ตาม webhook ถูกเริ่มโดยเซิร์ฟเวอร์ และลูกค้ารับได้แค่ข้อมูลและประมวลผลข้อมูล อย่างไรก็ตาม เนื่องจากกลไกที่แตกต่างกันของทั้งสอง webhook สามารถทำการซิงโครไนซ์ข้อมูลแบบเรียลไทม์ซึ่งไม่สามารถทำได้โดย polling ## ควรเลือกอันไหนดี? จากกลไกของ polling และ webhook การปฏิบัติทั่วไปคือเลือกร polling เมื่อข้อมูลมีการอัพเดทเป็นประจำและความต้องการเรียลไทม์ของข้อมูลไม่เข้มงวด ในกรณีอื่น ๆ webhooks จะเป็นเลือกที่ดีกว่า อย่างไรก็ตาม เมื่อต้องเลือกใช้ webhook นักพัฒนาควรให้ความสำคัญกับข้อกังวลดังต่อไปนี้: 1. หากระบบพึ่งพาข้อมูลที่ได้รับสูง ควรพิจารณาแผนสำรองเพื่อได้รับข้อมูลเมื่อ webhook ล้มเหลวและข้อมูลไม่สามารถซิงโครไนซ์ได้ รวมถึงแต่มิใช่จำกัดเฉพาะ polling หรือการกำหนดให้ webhook มีกลไกการส่งซ้ำ ฯลฯ 2. ในส่วนของลูกค้าที่จะรับ webhook นั้น ควรมีการตรวจสอบ API secret และลายเซ็นเนื้อหาฯลฯ เพื่อป้องกันไม่ให้เกิดการโจมตีของแฮกเกอร์ด้วยการทำ faking webhook 3. เนื่องจาก webhook อาจส่งคำขอซ้ำได้ ต้องการจัดการที่สอดคล้องกันในเวลานี้เพื่อป้องกันการทำข้อมูลซ้ำและไม่สอดคล้องกัน Logto ซึ่งเป็นโซลูชั่นการระบุตัวผู้ใช้ที่ได้รับความนิยมสูงเสมอนั้น มีฉาก webhook ที่หลากหลายและมีความปลอดภัยที่ยอดเยี่ยม การใช้ Logto เป็นระบบระบุตัวของผลิตภัณฑ์คุณ สามารถบูรณาการได้ง่ายและติดตั้งในหลายๆฉากแอปพลิเคชัน