หนึ่งในสิ่งที่ดีมากในบริษัทที่ทำอยู่คือ มีการพูดคุยแลกเปลี่ยนเกี่ยวกับ software development กันตลอดเวลาทั่วโลก เผอิญได้ไปเจอ discussion ที่น่าสนใจเกี่ยวกับการมีอยู่ของ backend-for-frontend (BFF) จึงนำมาสรุปไว้นิดหน่อย

ทำความรู้จักกับ Backend-for-frontend

ปัจจุบันระบบงานของเรา ซึ่งมาในรูปแบบของ API service จะต้องรองรับ client ที่มาในหลากหลายรูปแบบด้วยกัน เช่น web browser หรือ mobile app ทีนี้เรามี API อยู่แค่รูปแบบเดียวที่ต้องรองรับหลาย client ปัญหาจะเกิดถ้าแต่ละ client ต้องการรุปแบบข้อมูลที่ไม่เหมือนกัน หรือ จำนวนของข้อมูลที่ไม่เท่ากัน เพราะเราต้องปรับแก้ API ให้ใช้ร่วมกันได้ ซึ่งมันก็มีโอกาสที่ code จะผูกติดและซับซ้อนมากขึ้น ดูแลรักษายากขึ้น

ด้วยปัญหาที่ว่ามานี้ จึงมีแนวคิดที่ทำการแยก API ตามชนิดของ client ไปเลย นั่นก็คือ backend-for-frontend (BFF) นั่นเอง

ก่อนมี BFF

Before BFF

หลังจากมี BFF

After BFF

https://philcalcado.com/2015/09/18/the_back_end_for_front_end_pattern_bff.html

ข้อเสียของ BFF

ด้วยความที่ BFF เป็น technique ที่ได้รับความนิยมมากขึ้น เรามักจะมองแต่ข้อดีและข้ามข้อเสียของมันไป กลายเป็นว่าทุกระบบจะต้องมี BFF นะ ใน discuss จึงได้พูดถึงมีข้อเสียมากมายที่ต้องตามมา เช่น

  • ค่าใช้จ่ายทางด้าน infrastructure ที่สูงขึ้นตามการใช้งาน
  • การจัดการ authentication/authorization และ การ scale ตาม zone และ region ก็สามารถทำได้ด้วย API Gateway ซึ่งจัดการให้เองทั้งหมดโดยไม่ต้องทำเองเหมือน BFF
  • ไม่เหมาะสำหรับทีมพัฒนาเล็กๆ เพราะสามารถพูดคุยเพื่อเปลี่ยนแปลง frontend หรือ backend ได้ง่ายอยู่แล้ว การมาของ BFF จึงเป็น overhead ไป
  • ในเรื่องของ performance ระบบของเราจะมี latency ระหว่าง client -> BFF และ backend -> BFF เพิ่มอีก 1 hop
  • BFF ไม่มีความจำเป็นถ้ามี client เชื่อมต่อแค่รูปแบบเดียว
  • มีความเสี่ยงที่ BFF จะกลายเป็น orchestrator service (เป็น service ที่รวม business logic จาก backend อีกที) ไปแทน เนื่องจากมีการแบ่ง context หรือออกแบบ domain ได้ไม่ดีพอ ทำให้ BFF มีขนาดใหญ่มาก (หมายถึง code)

ข้อดีของ BFF

นอกจากประโยชน์ที่ยกมาในหัวข้อแรก มันยังมีผลพลอยได้เพิ่มเติม อย่างเช่น

  • BFF เหมาะสำหรับระบบที่มีข้อจำกัดทาง security ว่าห้ามเปิด backend API ออกสู่ client ตรงๆ
  • โดยทั่วไปแล้ว BFF สามารถเปลี่ยนแปลงได้เร็วกว่า client อย่างใน mobile app จะมีขั้นตอนเพิ่มเติม พวก iOS หรือ Android จะมีการ publish app ขึ้น App Store หรือ Play Store
  • การใช้งาน BFF จะช่วยลดความซับซ้อนในการทำ authentication/authorization ของ client ได้ เพราะมีแนวโน้มที่จะเปลี่ยนแปลงได้ยาก

จะเห็นว่า architecture decision มันมี ข้อดี-ข้อเสีย ของมัน ดังนั้นเราควรวิเคราะห์ผลกระทบที่จะเกิดขึ้นก่อนที่จะเลือกใช้ เพราะแต่ละการตัดสินใจย่อมมีค่าใช้จ่าย แน่นอนว่า BFF ก็เช่นกัน