Notify แพลตฟอร์มรวมแจ้งเตือน: อีเมล, Slack, LINE และ Webhooks
เรียนรู้เบื้องหลังการสร้าง Notify แพลตฟอร์มศูนย์รวมระบบแจ้งเตือนแบบครบวงจร รองรับ 4 ช่องทาง พัฒนาแล้วเสร็จภายในเวลาสองเดือนครึ่ง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- รวมโค้ดแจ้งเตือนอีเมล, Slack, LINE และ Webhooks ไว้ในแพลตฟอร์มกลางเดียว
- สถาปัตยกรรมแยกผลลัพธ์การส่งออกเป็นสถานะพิเศษ เช่น การข้ามหรือการปฏิเสธในตัวตอบกลับ 200
- พัฒนาต่อเนื่องจนถึงเดือนกันยายน 2026 มีโครงการลงทะเบียนใช้งานแล้ว 13 โปรเจกต์
- ย้ายระบบสู่โฮสติ้งจัดการอย่าง AWS Amplify หลังประสบปัญหาทันเนลหลุดในเดือนสิงหาคม 2026
เมื่อบริษัทเติบโตและมีผลิตภัณฑ์เพิ่มมากขึ้น ฟังก์ชันพื้นฐานอย่างระบบเข้าสู่ระบบ ระบบเรียกเก็บเงิน และระบบแจ้งเตือนกลายเป็นสิ่งจำเป็นสำหรับทุกผลิตภัณฑ์ ทีมงานจึงได้รวมระบบเข้าสู่ระบบไว้ที่แพลตฟอร์ม ELN ID และรวมระบบเรียกเก็บเงินไว้ในแพลตฟอร์มเฉพาะเรียบร้อยแล้ว บทความนี้จึงนำเสนอองค์ประกอบลำดับที่สามในกลุ่มเดียวกัน นั่นคือแพลตฟอร์มแจ้งเตือนที่มีชื่อว่า notify
จุดเริ่มต้นเกิดขึ้นจากการตรวจสอบโค้ดการแจ้งเตือนทั่วทั้งผลิตภัณฑ์ของบริษัท ไม่ว่าจะเป็นผลิตภัณฑ์ซัพพอร์ต ผลิตภัณฑ์มอนิเตอร์ และเว็บไซต์องค์กร ซึ่งต่างมีโค้ดแยกDrเป็นของตัวเอง โดยใช้บริการ Amazon SES สำหรับอีเมล และเว็บพุกสำหรับโพสต์ลง Slack โค้ดเหล่านี้ถูกเขียนขึ้นโดยบุคคลที่แตกต่างกันในเวลาที่ต่างกัน ทำให้รายละเอียดการทำงานมีความแตกต่างกันไปในแต่ละจุด
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
[[IMAGE_ai-insight]]
การรวมศูนย์ระบบแจ้งเตือน (Centralized Notification Platform) เป็นแนวทางสำคัญในสถาปัตยกรรมซอฟต์แวร์สมัยใหม่ที่ช่วยลดการเขียนโค้ดซ้ำซ้อน (Duplicated Code) และควบคุมมาตรฐานความปลอดภัย รวมถึงการจัดการข้อผิดพลาด (Error Handling) ให้เป็นรูปแบบเดียวกัน การแยกแพลตฟอร์มแจ้งเตือนออกมาเป็นอิสระช่วยให้ทีมพัฒนาผลิตภัณฑ์อื่นๆ ไม่ต้องกังวลกับการเชื่อมต่อ API ของแต่ละช่องทางสื่อสารด้วยตนเอง
การพัฒนาเริ่มต้นขึ้นเมื่อปลายเดือนมิถุนายน 2026 โดยทีมงานได้แยกโค้ดส่งอีเมลออกจากเว็บไซต์องค์กรให้อยู่ในรูปของไลบรารี ต่อมาในวันที่ 16 กรกฎาคม จึงได้บันทึกการตัดสินใจทางสถาปัตยกรรม (Architecture Decision Record) ว่า notify จะเป็นผลิตภัณฑ์จริงที่มีหน้าจอและ API เป็นของตัวเอง และในวันถัดมา ทีมงานได้สร้างระบบรองรับ 4 ช่องทาง ระบบจัดลำดับการส่ง คอนโซลแอดมิน และ SDK เสร็จสิ้นในคราวเดียว
ในมุมมองของผลิตภัณฑ์ที่เรียกใช้งาน notify การแจ้งเตือนจะมีผลลัพธ์ที่ไม่ใช่ความสำเร็จหรือข้อผิดพลาดในการสื่อสารเสมอ เช่น การข้ามเนื่องจากมี ID การส่งเดียวกันถูกประมวลผลไปแล้ว หรือการไม่ส่งเนื่องจากผู้รับเลือกปฏิเสธ สิ่งเหล่านี้ไม่ใช่ความผิดปกติ แต่เป็นการทำงานที่ถูกต้องตามหน้าที่ของแพลตฟอร์ม ซึ่งระบบจะส่งผลลัพธ์เหล่านี้กลับมาในบอดี้ของ HTTP 200 ปกติ แทนที่จะเป็นรหัสข้อผิดพลาด 4xx
"A countermeasure that is designed but not deployed protects nothing."
Dev.to
ระบบตรวจสอบต้นทุนของบริษัทแสดงให้เห็นว่าเหตุผลนี้มีความสำคัญอย่างไรในทางปฏิบัติ โดยระบบจะปฏิบัติกับผลลัพธ์ที่ถูกส่งซ้ำว่าเป็น "ส่งแล้ว แต่ไม่ใช่ข้อมูลล่าสุดในครั้งนี้" ซึ่งการแบ่งแยกระหว่าง "ส่งไปถึงหรือไม่" กับ "เราเพิ่งส่งใหม่หรือไม่" จะเกิดขึ้นได้ก็ต่อเมื่อผลลัพธ์ยังคงอยู่ในบอดี้ของการตอบกลับเท่านั้น
เมื่อถึงเดือนกันยายน 2026 มีโครงการลงทะเบียนใช้งานแล้ว 13 โปรเจกต์ และมีความต้องการใช้งานจากผลิตภัณฑ์ที่มีรูปทรงแตกต่างกันอย่างมากหลั่งไหลเข้ามาอย่างต่อเนื่อง เช่น ความต้องการเลือกช่อง Slack ผ่าน UI นำไปสู่การสร้างแอป Slack แบบเฟิสต์คลาส และความต้องการอีเมลยืนยันตัวตนในภาษาของผู้ใช้ก็นำไปสู่เทมเพลตรายภาษา
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น