ทำความรู้จัก Backend For Frontends (BFF) กัน

จาก ThoughtWorks Technology Radar นั้น มีเทคนิคที่น่าสนใจ คือ BFF (Backend For Frontends) เนื่องจากในปัจจุบันระบบงาน จำเป็นต้องสนับสนุน client มากมาย ไม่ว่าจะเป็น web browser, mobile และ embedded system จากเดิมเราจะทำการสร้าง Backend APIs เพียงตัวเดียวสำหรับทุกอย่าง แต่เรากลับลืมไปว่าแต่ละ client นั้น มีหลายสิ่งที่แตกต่างกันทั้ง hardware, performance และขนาดของ network ดังนั้น สิ่งที่เราควรจะทำก็คือ แยกBackend APIs ตามชนิดของ client ซึ่งถูกเรียกว่า Backend For Frontends (BFF) นั่นเอง

จาก blog เรื่อง BFF ของระบบ SoundCloud

อธิบายประสบการณ์จากการการเปลี่ยนแปลงโครงสร้างของระบบ มาดูกันว่าเป็นอย่างไรบ้าง ? แต่ก่อนโครงสร้างระบบ SoundCloud นั้น จะสร้าง APIs เดียวสำหรับใช้งานจากทั้ง Web, Android และ iOS แสดงดังรูป

แต่ปัญหาเริ่มเกิดขึ้นเมื่อระบบใหญ่ขึ้นและมีจำนวน feature มากขึ้น

ส่งผลให้ต้องใช้เวลาในการพัฒนาสูงเพิ่มขึ้นอย่างมาก !! ทั้ง Web, Android และ iOS ต่างต้องการใช้ APIs ที่แตกต่างกัน เนื่องจาก Mobile ต้องการข้อมูลที่เล็ก และ เร็ว มีจำนวนการใช้งานที่สูงกว่า มีขนาดของ network ที่จำกัดกว่า ดังนั้นจึงต้องเกิดการเปลี่ยนแปลงขึ้นมา แต่สิ่งที่ยากก็คือ ทั้งฝั่ง Frontend และ Backend ต้องคุยกันอย่างมาก และปัญหาจะเริ่มมากขึ้นในฝั่ง Backend เนื่องจากการสร้าง APIs ใหม่ ๆ มารองรับการใช้งานจากทางฝั่ง Frontend บนระบบเก่าที่มันทำทุกสิ่งทุกอย่าง ดังนั้นวิธีการแก้ไขที่ง่าย และ ได้ผลมาก ๆ คือ สร้างส่วนการทำงานใหม่ขึ้นมาสำหรับผู้ใช้งานกลุ่มหรือชนิดนั้น ๆ ไปเลย ซึ่งตอนนี้ BFF ได้เริ่มถือกำเนิดมาแล้ว !! แสดงดังรูป เห็นไหมว่า เราได้ทำการเพิ่ม layer การทำงานใหม่ขึ้นมา เพื่อแก้ไขปัญหาที่เราพบเจอ แต่มันก็คือการสร้างปัญหา N+1 ขึ้นมาเช่นเดียวกัน รวมทั้งก่อให้เกิดปัญหาอีกมากมาย เช่น ทีมฝั่ง Backend จะมีงานที่เยอะมากขึ้น งานเข้าเยอะนะสิ !! ดังนั้น ฝั่ง Frontend จำเป็นต้องเขียน Backend ด้วย แต่ฝั่ง Backend นั้นต้องเขียนง่าย ๆ เล็ก ๆ ไม่ยาก รวมทั้งต้องมีระบบ Monitoring, Alert และ Authentication ด้วยนะ ทำให้เกิดมาตรฐานที่เหมาะสมกับ BFF ของแต่ละระบบนั่นเอง

เมื่อเราทำการสร้าง BFF สำหรับ API ต่าง ๆ ได้แล้ว มันมีประโยชน์ดังนี้

ถ้าเราต้องการเปลี่ยน หรือ ย้ายการทำงานจากระบบเดิม ไปยังระบบใหม่ หรือ สถาปัตยกรรมใหม่ ๆ สามารถทำได้ง่ายขึ้น เนื่องจากเพียงแก้ไขที่ BFF ได้เลย และสามารถเปลี่ยนแบบบางส่วนได้อีกด้วย นั่นคือการลดความเสี่ยงด้วยนะ แสดงดังรูป ประโยชน์ที่ได้ตามมาประกอบไปด้วย

• แยกการทำงานออกเป็นส่วน ๆ
• เพื่อความสามารถต่าง ๆ เข้าไปได้ง่าย
• สามารถ share library ได้ง่าย
• สามารถ deploy ได้ง่าย
• ลดผลกระทบจากการเปลี่ยนแปลงต่าง ๆ

ในปัจจุบันสถาปัตยกรรมของ SoundCloud ได้พัฒนาและปรับปรุงมาเยอะมาก ๆ

ซึ่งมีกฎที่น่าสนใจอยู่ว่า จะใช้ share library เมื่อ library ชุดนั้นมันไม่ทำการเปลี่ยนแปลง แต่ถ้ายังทำการเปลี่ยนแปลงบ่อย ๆ แนะนำให้ใช้งานผ่าน service แทน และให้เน้นไปที่ feature และการใช้งานของผู้ใช้งานเป็นหลัก ก่อนที่จะไปมองว่าจะ reuse หรือลด duplication อย่างไร แสดงดังรูป

โดยสรุปแล้ว BFF มันเป็นแนวทางที่ดี

สำหรับการสร้างสิ่งต่าง ๆ ให้เหมาะสมกับผู้ใช้งาน มันช่วยทำให้สร้างระบบที่เหมาะสมขึ้นมา สามารถส่งมอบประสบการณ์การใช้งานที่ดี สามารถส่งมอบ feature ต่าง ๆ ได้รวดเร็วขึ้น รวมทั้งยังเปิดโอกาสให้เราพัฒนา และ ปรับปรุงระบบได้ง่ายขึ้นอีกด้วย