Screen Shot 2558-12-21 at 6.10.48 PM
จาก 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
แสดงดังรูป

01

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

ส่งผลให้ต้องใช้เวลาในการพัฒนาสูงเพิ่มขึ้นอย่างมาก !!
ทั้ง Web, Android และ iOS ต่างต้องการใช้ APIs ที่แตกต่างกัน
เนื่องจาก Mobile ต้องการข้อมูลที่เล็ก และ เร็ว
มีจำนวนการใช้งานที่สูงกว่า
มีขนาดของ network ที่จำกัดกว่า

ดังนั้นจึงต้องเกิดการเปลี่ยนแปลงขึ้นมา
แต่สิ่งที่ยากก็คือ ทั้งฝั่ง Frontend และ Backend ต้องคุยกันอย่างมาก
และปัญหาจะเริ่มมากขึ้นในฝั่ง Backend
เนื่องจากการสร้าง APIs ใหม่ ๆ มารองรับการใช้งานจากทางฝั่ง Frontend
บนระบบเก่าที่มันทำทุกสิ่งทุกอย่าง

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

02

เห็นไหมว่า เราได้ทำการเพิ่ม layer การทำงานใหม่ขึ้นมา
เพื่อแก้ไขปัญหาที่เราพบเจอ
แต่มันก็คือการสร้างปัญหา N+1 ขึ้นมาเช่นเดียวกัน

รวมทั้งก่อให้เกิดปัญหาอีกมากมาย เช่น
ทีมฝั่ง Backend จะมีงานที่เยอะมากขึ้น
งานเข้าเยอะนะสิ !!
ดังนั้น ฝั่ง Frontend จำเป็นต้องเขียน Backend ด้วย
แต่ฝั่ง Backend นั้นต้องเขียนง่าย ๆ เล็ก ๆ ไม่ยาก
รวมทั้งต้องมีระบบ Monitoring, Alert และ Authentication ด้วยนะ
ทำให้เกิดมาตรฐานที่เหมาะสมกับ BFF ของแต่ละระบบนั่นเอง

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

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

03

ประโยชน์ที่ได้ตามมาประกอบไปด้วย

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

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

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

และให้เน้นไปที่ feature และการใช้งานของผู้ใช้งานเป็นหลัก
ก่อนที่จะไปมองว่าจะ reuse หรือลด duplication อย่างไร

แสดงดังรูป

04

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

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