Backend​ ​Development​ ​คือ​อะไร​ ​และ​ทำ​หน้าที่​อะไร​อยู่​เบื้อง​หลัง​ ​Web​ ​Application

Backend Development คือการพัฒนาส่วนที่รับคำขอและประมวลผลบน Server เช่น ตรวจตัวตนและสิทธิ์ ใช้กฎธุรกิจ อ่านหรือบันทึกข้อมูล ติดต่อระบบภายนอก แล้วตอบผลให้ Frontend ผู้ใช้มักไม่เห็นโค้ดส่วนนี้โดยตรง แต่ผลของมันกำหนดว่าระบบให้ข้อมูลถูกคน ถูกเวลา และถูกกฎหรือไม่

หนึ่งคำขอผ่านอะไรบ้าง

เมื่อผู้ใช้กด “ส่งคำขอ” Frontend ส่งข้อมูลไปยัง API Backend ตรวจว่าผู้ใช้มีสิทธิ์และข้อมูลครบ ใช้กฎว่าคำขอชนิดนี้เปิดได้หรือไม่ บันทึกฐานข้อมูล แล้วตอบเลขอ้างอิงหรือข้อผิดพลาดที่เหมาะสม การตรวจใน Browser ช่วยประสบการณ์ใช้งาน แต่ Backend ต้องตรวจซ้ำเพราะคำขอสามารถส่งตรงมาที่ API ได้

ภาพที่ 1: Backend เป็นจุดบังคับกฎและขอบเขตข้อมูลก่อนส่งผลกลับสู่หน้าจอ

งานที่มักมองไม่เห็น

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

ตัวอย่างสมมติ: ระบบคิว

ผู้ใช้สองคนจองเวลาเดียวกันเกือบพร้อมกัน Frontend ของทั้งคู่เห็นว่าว่างจากข้อมูลก่อนหน้า Backend ต้องบังคับกฎไม่ให้ยืนยันสองรายการในเวลาเดียวกันและตอบให้คนที่ไม่สำเร็จเลือกเวลาใหม่ ปัญหานี้แก้ด้วยการซ่อนเวลาบนหน้าจออย่างเดียวไม่ได้ เพราะข้อมูลอาจเปลี่ยนระหว่างที่ผู้ใช้กำลังกด

ใช้ในรายงาน

วาด Request–Response หนึ่งกรณี พร้อมจุดตรวจข้อมูล สิทธิ์ กฎธุรกิจ และการบันทึก แสดงผลสำเร็จและผิดพลาดแยกกัน ระบุสิ่งที่ตรวจได้จากโค้ด/การทดสอบกับสิ่งที่ยังต้องตรวจในสภาพใช้งานจริง ไม่ใช้คำว่า “Backend ปลอดภัย” โดยไม่มีหลักฐาน

อ่าน REST API และ Authentication กับ Authorization หรือดู บริการ Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

หลักฐานที่ควรแสดงคือ ลำดับรับ Request, validate, authorize, ใช้กฎธุรกิจ และตอบ status ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

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

แหล่งข้อมูลประกอบ

• MDN: Introduction to the server side — บทบาทการประมวลผลฝั่ง Server
• MDN: Client-server overview — ลำดับคำขอและผลตอบกลับ