เจาะลึกวิธีสร้างระบบรับ Feedback ด้วย TypeScript และ PostgreSQL ไม่ให้กลายเป็นกล่องข้อความร้าง

การติดตั้งปุ่มรับความคิดเห็นหรือ Feedback Button ไว้บนเว็บไซต์หรือแอปพลิเคชันเป็นเรื่องที่ทำได้ง่ายดายในปัจจุบัน แต่ความท้าทายที่แท้จริงไม่ได้อยู่ที่ฟอร์มรับข้อมูล หากแต่อยู่ที่กระบวนการจัดการหลังจากที่ผู้ใช้งานกดปุ่มส่งข้อมูลเข้ามาแล้ว โดยบทความนี้ได้นำเสนอแนวทางการสร้างระบบรับ Feedback ขนาดเล็กแต่ใช้งานได้จริงด้วยสถาปัตยกรรมที่ประกอบไปด้วย TypeScript, Express และ PostgreSQL ซึ่งสามารถประยุกต์ใช้ได้ทั้งกับการแจ้งเตือนบั๊ก คำขอฟีเจอร์ใหม่ คำถามสนับสนุน หรือการสนทนาภายในผลิตภัณฑ์

วงจรชีวิตของระบบรับ Feedback ที่มีประโยชน์ควรประกอบไปด้วยการรับข้อมูลผ่านเบราว์เซอร์หรือแอปพลิเคชัน ส่งต่อไปยัง Feedback API จัดเก็บลงในฐานข้อมูล PostgreSQL ผ่านกระบวนการ Transactional Outbox และส่งต่อไปยัง Notification Worker ก่อนจะกระจายไปยังช่องทางสื่อสารอย่างเช่นแชท อีเมล หรือระบบติดตามปัญหา โดยมีหลักการสำคัญคือ PostgreSQL ทำหน้าที่เป็นแหล่งข้อมูลที่เชื่อถือได้ (Source of Truth) ส่วนเครื่องมือแชทหรืออีเมลเป็นเพียงพื้นผิวสำหรับการส่งมอบเท่านั้น ไม่ใช่ฐานข้อมูล

ในการออกแบบฐานข้อมูล นักพัฒนาควรเปิดใช้งาน UUID และสร้างตารางที่จำเป็นอย่างระมัดระวัง พร้อมทั้งหลีกเลี่ยงการบันทึกข้อมูลบริบทที่เข้าข่ายล่วงละเมิดความเป็นส่วนตัว เช่น Access Tokens, เนื้อหาในฟอร์มทั้งหมด, URL เต็มรูปแบบ, ข้อมูลใน Local Storage หรือคุณลักษณะของผู้ใช้ที่มีความอ่อนไหว นอกจากนี้ ในส่วนของการเก็บข้อมูลทางเทคนิคควรทำตั้งแต่ตอนที่ผู้ใช้ส่งรายงานเข้ามาทันที เพื่อหลีกเลี่ยงการต้องมานั่งถามผู้ใช้ภายหลังว่าใช้งานหน้าจอหรือเวอร์ชันไหนอยู่

ปัญหาคลาสสิกอย่างหนึ่งในการทำระบบแจ้งเตือนคือ หากระบบทำการบันทึกข้อมูลลงฐานข้อมูลแล้วเกิดแอปพลิเคชันแครชก่อนที่จะส่งการแจ้งเตือน ข้อความนั้นจะถูกละเลยโดยไม่มีใครรู้ หรือหากสลับลำดับเป็นการแจ้งเตือนก่อนแล้วค่อยบันทึกฐานข้อมูล ก็อาจเกิดกรณีที่การแจ้งเตือนสำเร็จแต่บันทึกข้อมูลไม่สำเร็จ ทางออกที่ปลอดภัยคือการใช้ Transactional Outbox ซึ่งจะทำการคอมมิตข้อมูลรายงานคำขอแจ้งเตือนไปพร้อมกันในธุรกรรมเดียว และให้ Worker หลายตัวสามารถดึงงานไปทำได้อย่างปลอดภัยผ่านคำสั่ง FOR UPDATE SKIP LOCKED พร้อมทั้งกำหนดให้ย้ายงานไปยังสถานะ Dead-Letter หากพบความล้มเหลวเกินจำนวนครั้งที่กำหนด

การจัดการความคิดเห็นที่ดีต้องไม่ใช่แค่การรับข้อความเข้ามาแล้วจบไป แต่ต้องมีการคัดกรอง (Triage) ที่บันทึกทั้งการเปลี่ยนแปลงสถานะและประวัติความเป็นมา คำขอฟีเจอร์ใหม่ไม่จำเป็นต้องถูกนำไปใส่ไว้ในแผนงาน (Roadmap) เสมอไป การระบุสถานะว่า "ตรวจสอบและปิดงานแล้ว" ถือเป็นผลลัพธ์ที่ใช้ได้เช่นกันหากมีความชัดเจน นอกจากนี้ ช่องทางรับ Feedback จะยังคงมีสุขภาพที่ดีได้ก็ต่อเมื่อการละเลยข้อความสามารถวัดผลได้จริง โดยเริ่มต้นจากการกำหนดเกณฑ์ความพร้อมจากคำมั่นสัญญาของบริการที่ทีมสามารถรักษาไว้ได้จริง และหลีกเลี่ยงการติดป้ายว่าช่องทางนี้ใช้งานแบบสด (Live) หากไม่มีทีมงานคอยมอนิเตอร์ตลอดเวลา

ที่มา: Dev.to