Backend for Frontend (BFF): ทางออกสถาปัตยกรรม
เจาะลึกรูปแบบ Backend for Frontend (BFF) ทางออกของสถาปัตยกรรมไมโครเซอร์วิส ช่วยจัดการความต้องการข้อมูลที่แตกต่างระหว่างเว็บและมือถือ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- BFF แยกแบกสำหรับแต่ละหน้าบ้าน
- แก้ปัญหา Over-fetching และ Under-fetching
- แยกการจัดการความปลอดภัยแต่ละไคลเอนต์
- ลดความซับซ้อนของแบ็คเอนด์หลัก
ในยุคที่แอปพลิเคชันต้องรองรับทั้งหน้าเว็บไซต์บนเดสก์ท็อป แท็บเล็ต และแอปพลิเคชันมือถือ นักพัฒนาซอฟต์แวร์มักต้องเผชิญกับปัญหาคลาสสิก เมื่อหน้าบ้านแต่ละประเภทต้องการข้อมูลในรูปแบบและปริมาณที่ไม่เหมือนกัน การพยายามปรับ API ตัวเดียวให้ตอบสนองความต้องการทั้งหมดมักจะจบลงด้วยการส่งข้อมูลส่วนเกินหรือข้อมูลที่ไม่เพียงพอมาให้ไคลเอนต์ใช้งาน
แนวทางแบบดั้งเดิมที่ใช้แบ็คเอนด์ตัวเดียวให้บริการทุกแพลตฟอร์มมักสร้างความปวดหัวให้กับทีมพัฒนา เนื่องจากความต้องการของแอปพลิเคชันมือถือที่ต้องการข้อมูลกระชับรวดเร็ว แตกต่างอย่างสิ้นเชิงกับหน้าเว็บไซต์ที่ต้องการข้อมูลเชิงลึกในหน้าเดียว การสร้างเอนด์พอยต์เดียวที่คืนค่าฟิลด์จำนวนมากจึงทำให้ระบบมีความซับซ้อนและดูแลรักษาได้ยากยิ่งขึ้น
สถาปัตยกรรม Backend for Frontend (BFF) ทำหน้าที่เป็นชั้นตัวกลางที่คอยแปลงและจัดระเบียบข้อมูลให้เข้ากับความต้องการเฉพาะของไคลเอนต์แต่ละตัว โดยไม่ไปรบกวนตรรกะทางธุรกิจหลักที่อยู่ข้างหลัง แนวคิดนี้ช่วยให้ทีมพัฒนาหน้าบ้านสามารถปรับเปลี่ยนอินเทอร์เฟซได้อย่างอิสระโดยไม่ต้องรอแก้ระบบหลังบ้าน
รูปแบบการทำงานของสถาปัตยกรรม BFF แบ่งออกเป็นสัดส่วนชัดเจนตามประเภทของไคลเอนต์:
- Frontend Web เชื่อมต่อไปยัง BFF Web แล้วจึงเข้าสู่ Backend หลัก
- Frontend Mobile เชื่อมต่อไปยัง BFF Mobile แล้วจึงเข้าสู่ Backend หลัก
- Frontend Admin เชื่อมต่อไปยัง BFF Admin แล้วจึงเข้าสู่ Backend หลัก
ข้อดีหลักของการนำสถาปัตยกรรมนี้มาใช้ประกอบด้วยการตัดปัญหาการดึงข้อมูลเกินความจำเป็น ช่วยให้อุปกรณ์มือถือประหยัดปริมาณการใช้ข้อมูลและโหลดหน้าจอได้เร็วขึ้น นอกจากนี้ยังช่วยให้แต่ละ BFF สามารถกำหนดกฎระเบียบการยืนยันตัวตนและการอนุญาตสิทธิ์ที่แตกต่างกันได้ตามความเหมาะสมของแพลตฟอร์มนั้น ๆ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
อย่างไรก็ตาม การใช้งาน BFF ก็มีข้อควรระวังและอุปสรรคที่ต้องคำนึงถึงเช่นกัน เช่น การเพิ่มขึ้นของจำนวนเซอร์วิสที่ต้องดูแลจัดการ ความเสี่ยงในการเผลอนำตรรกะทางธุรกิจที่ซับซ้อนมาใส่ไว้ในชั้น BFF จนทำให้เกิดความซ้ำซ้อน รวมถึงความจำเป็นในการใช้เครื่องมือพื้นฐานอย่างเช่น Kubernetes หรือการทำระบบติดตามการทำงานแบบกระจาย เพื่อป้องกันปัญหาคอขวดและอาการหน่วงของเครือข่าย
แนวปฏิบัติที่ดีที่สุดในการใช้งานรูปแบบนี้คือการเริ่มต้นจากจุดเล็ก ๆ โดยเลือกนำไปใช้กับหน้าบ้านที่ประสบปัญหามากที่สุดก่อน เช่น แอปพลิเคชันมือถือ เมื่อเห็นผลลัพธ์ที่ชัดเจนจึงค่อยขยายผลไปยังส่วนอื่น ๆ พร้อมทั้งใช้เทคนิคการเรียกข้อมูลแบบขนานและระบบแคชเพื่อเพิ่มประสิทธิภาพการทำงานสูงสุด
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น