Backend for Frontend (BFF) คืออะไร

Backend for Frontend (BFF) คือบริการแบ็กเอนด์เฉพาะที่สร้างขึ้นสำหรับส่วนหน้า (frontend) หนึ่งๆ แทนที่ไคลเอนต์ทุกประเภท (เว็บ, iOS, Android, บุคคลที่สาม) จะต้องสื่อสารกับแบ็กเอนด์อเนกประสงค์เดียวกัน แต่ละประเภทจะมีเลเยอร์ฝั่งเซิร์ฟเวอร์ของตัวเองที่รวบรวมและปรับเปลี่ยนข้อมูลจากไมโครเซอร์วิสของคุณให้เป็นรูปแบบข้อมูลที่ส่วนหน้านั้นต้องการได้อย่างแม่นยำ

Sam Newman ได้ตั้งชื่อและทำให้รูปแบบนี้เป็นที่นิยมในปี 2015 โดยอ้างอิงจากงานที่ทำที่ SoundCloud กว่าทศวรรษต่อมา รูปแบบ BFF ยังคงเป็นเครื่องมือมาตรฐานสำหรับทีมที่รันไมโครเซอร์วิสที่อยู่เบื้องหลังแอปพลิเคชันไคลเอนต์หลายตัว และ Microsoft ได้บันทึกไว้ว่าเป็นรูปแบบสถาปัตยกรรมคลาวด์หลัก

ปัญหาที่ BFF แก้ไข

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

สิ่งนี้ทำให้เกิดปัญหาสองประการที่เกิดขึ้นซ้ำๆ

การดึงข้อมูลเกิน (Over-fetching) และการดึงข้อมูลไม่พอ (Under-fetching) ปลายทางแบบทั่วไป (general-purpose endpoint) จะคืนค่าข้อมูลในรูปแบบที่ตายตัว แดชบอร์ดบนเดสก์ท็อปอาจต้องการบันทึกข้อมูลลูกค้าทั้งหมดพร้อมประวัติการสั่งซื้อ, คำแนะนำ, และการตั้งค่าบัญชีในการตอบกลับครั้งเดียว ส่วนแอปมือถือที่ใช้การเชื่อมต่อเซลลูลาร์ที่ไม่เสถียรอาจต้องการเพียงสามฟิลด์และไม่มากไปกว่านั้น เมื่อทั้งคู่เรียกใช้ปลายทางเดียวกัน หนึ่งในนั้นจะได้รับข้อมูลที่ไม่ถูกต้อง ไคลเอนต์มือถืออาจดาวน์โหลดข้อมูลจำนวนมากเกินไปที่ต้องทิ้ง (over-fetching) หรือต้องทำการเรียกข้อมูลหลายครั้งเพื่อรวบรวมสิ่งที่ต้องการ (under-fetching)

ไคลเอนต์ที่ "ช่างคุย" (Chatty clients) เมื่อแบ็กเอนด์ไม่ได้ถูกปรับแต่งมาสำหรับหน้าจอใดหน้าจอหนึ่ง ไคลเอนต์จะทำการเรียกข้อมูลหลายครั้งเพื่อชดเชย หน้าจอหลักของมือถือที่ต้องการข้อมูลโปรไฟล์, จำนวนการแจ้งเตือน, และฟีดข้อมูล อาจทำการร้องขอแยกกันสามหรือสี่ครั้งไปยังไมโครเซอร์วิสสามหรือสี่ตัว จากนั้นจึงนำผลลัพธ์มารวมกันบนอุปกรณ์ การเรียกข้อมูลเพิ่มเติมแต่ละครั้งจะเพิ่มความล่าช้าและสิ้นเปลืองแบตเตอรี่ และตรรกะการประสานงานจะรั่วไหลไปยังฝั่งไคลเอนต์ซึ่งยากต่อการทดสอบและจัดการเวอร์ชัน

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

รูปแบบ BFF ทำงานอย่างไร

รูปแบบ BFF นำเสนอเลเยอร์ฝั่งเซิร์ฟเวอร์ที่บางเบาซึ่งอยู่ระหว่างส่วนหน้าหนึ่งๆ กับบริการปลายน้ำของคุณ แต่ละอินเทอร์เฟซจะมีแบ็กเอนด์เป็นของตัวเอง

[ Web app ]    --->  [ Web BFF ]    ---\
[ iOS app ]    --->  [ iOS BFF ]    -----> [ Microservices ]
[ Android app] --->  [ Android BFF ] ---/

BFF แต่ละตัวทำงานสามอย่างสำหรับไคลเอนต์ของตน:

1. รวบรวม (Aggregate) มันเรียกไมโครเซอร์วิสปลายน้ำที่หน้าจอต้องการและรวมการตอบกลับเข้าด้วยกัน เพื่อให้ไคลเอนต์ทำการร้องขอครั้งเดียวแทนที่จะเป็นห้าครั้ง นี่คือการรวม API ที่นำไปใช้กับประสบการณ์ผู้ใช้เดียว หากคุณต้องการเวอร์ชันทั่วไปของแนวคิดนี้ โปรดดูคำอธิบายของเราเกี่ยวกับรูปแบบ API aggregator
2. ปรับเปลี่ยนรูปแบบ (Reshape) มันตัดฟิลด์ที่ไม่จำเป็น, เปลี่ยนชื่อสิ่งต่างๆ ให้เป็นคำที่ไคลเอนต์เข้าใจง่าย, ปรับโครงสร้างแบบซ้อนให้แบนลง, และจัดรูปแบบค่าตามที่อินเทอร์เฟซคาดหวัง BFF ของมือถือจะคืนค่าข้อมูลที่เบาบาง; BFF ของเดสก์ท็อปจะคืนค่าข้อมูลที่สมบูรณ์
3. แปล (Translate) มันจัดการข้อกังวลเฉพาะของไคลเอนต์ เช่น กลยุทธ์การแบ่งหน้า (pagination), การแคชการตอบกลับที่ปรับให้เหมาะกับไคลเอนต์นั้น, และการเลือกโปรโตคอล โดยไม่ต้องบังคับให้บริการที่ใช้ร่วมกันต้องตัดสินใจเรื่องเหล่านั้น

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

หนึ่ง BFF ต่อหนึ่งประสบการณ์ไคลเอนต์

คำแนะนำหลักของ Newman สั้นๆ คือ: หนึ่งประสบการณ์, หนึ่ง BFF หากแอป iOS และ Android ของคุณมีประสบการณ์ที่แตกต่างกันอย่างชัดเจน ให้แต่ละแอปมี BFF ของตัวเอง หากเว็บแอปและแอปมือถือแตกต่างกัน กฎเดียวกันก็ใช้ได้

ประเด็นของกฎนี้คือการทำให้ BFF แต่ละตัวมุ่งเน้น เมื่อ BFF เดียวพยายามให้บริการไคลเอนต์สองตัวที่มีความต้องการต่างกัน มันจะเริ่มสะสมตรรกะตามเงื่อนไข ("ถ้าเป็นมือถือ, คืนค่านี่; ถ้าเป็นเว็บ, คืนค่านั่น") และคุณก็จะกลับไปสู่แบ็กเอนด์ทั่วไปที่มีปัญหาการประสานงานแบบเดียวกันทั้งหมด BFF ที่มุ่งเน้นจะคงขนาดเล็ก ซึ่งเป็นคุณสมบัติที่ทำให้รูปแบบนี้คุ้มค่า

มีข้อยกเว้นที่สมเหตุสมผลที่ Newman เองก็ยกมาจาก SoundCloud: เมื่อทีมหนึ่งเป็นเจ้าของไคลเอนต์ที่คล้ายกันสองตัว เช่น แอป iOS และ Android ที่มีประสบการณ์เกือบจะเหมือนกัน การใช้ BFF มือถือเดียวร่วมกันก็เป็นเรื่องที่สมเหตุสมผล ปัจจัยในการตัดสินใจคือความเป็นเจ้าของและความคล้ายคลึง ไม่ใช่ชื่อแพลตฟอร์ม กฎนี้เป็นค่าเริ่มต้น ไม่ใช่กฎหมายที่ตายตัว

ความเป็นเจ้าของเป็นของทีมส่วนหน้า

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

เมื่อทีมส่วนหน้าเป็นเจ้าของ BFF พวกเขาสามารถควบคุมรอบการเผยแพร่, เลือกภาษาและรันไทม์, จัดลำดับความสำคัญของงานค้าง, และเผยแพร่การเปลี่ยนแปลงไปยังไคลเอนต์และบริการสนับสนุนพร้อมกัน การเปลี่ยนแปลง UI ที่ต้องการปลายทางรวมใหม่ไม่จำเป็นต้องยื่นคำร้องกับทีมแบ็กเอนด์แยกต่างหากและรอให้ผ่านคิวงานของทีมนั้น ทีมที่ประสบปัญหาจะเป็นผู้แก้ไข

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

BFF เทียบกับ API Gateway

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

API Gateway คือจุดเข้าใช้งานทั่วไปที่จัดการข้อกังวลข้ามสายงานสำหรับทราฟฟิกทั้งหมด: การยืนยันตัวตน, การจำกัดอัตรา, การกำหนดเส้นทาง, การสิ้นสุด TLS, และการบันทึกคำขอ มันเป็นของทีมแพลตฟอร์มหรือทีมโครงสร้างพื้นฐานและถูกออกแบบมาให้ไม่ขึ้นกับไคลเอนต์ เกตเวย์เดียวให้บริการทุกคนในลักษณะเดียวกัน

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

ทั้งสองสิ่งนี้ไม่ใช่คู่แข่งกัน ในการจัดวางในสภาพแวดล้อมการผลิตทั่วไป API Gateway จะอยู่ข้างหน้า จัดการการยืนยันตัวตน, การจำกัดอัตรา, และการตรวจสอบสำหรับทราฟฟิกทั้งหมด จากนั้นจึงกำหนดเส้นทางไคลเอนต์แต่ละรายไปยัง BFF เฉพาะของตนที่อยู่เบื้องหลังเกตเวย์ สถาปัตยกรรมอ้างอิงของ Microsoft แสดงให้เห็นสิ่งนี้อย่างชัดเจน: เกตเวย์จัดการข้อกังวลข้ามสายงาน โดยมี BFF แบบ serverless หนึ่งตัวต่อไคลเอนต์หนึ่งตัวอยู่เบื้องหลัง ใช้เกตเวย์สำหรับสิ่งที่เหมือนกันในไคลเอนต์ทั้งหมด และ BFF สำหรับสิ่งที่แตกต่างกัน (เราจะกล่าวถึงความแตกต่างนี้อย่างลึกซึ้งในบทความแยกต่างหาก; ในที่นี้เพียงพอที่จะทราบว่าพวกมันอยู่ในเลเยอร์ที่แตกต่างกันและตอบสนองความต้องการที่แตกต่างกัน)

สำหรับภาพรวมของเกตเวย์โดยรอบ การเปรียบเทียบที่เผยแพร่เหล่านี้ช่วยได้: การจัดการ API เทียบกับ API Gateway, API Gateway เทียบกับ Load Balancer, และ Service Mesh เทียบกับ API Gateway

เมื่อใดที่ควรใช้ BFF

รูปแบบนี้จะคุ้มค่าเมื่อเป็นไปตามเงื่อนไขเหล่านี้:

• คุณมีไคลเอนต์หลายตัวที่แตกต่างกันอย่างแท้จริง เช่น เว็บ, มือถือ, และการเชื่อมต่อกับพันธมิตร แต่ละตัวมีความต้องการข้อมูลที่แตกต่างกัน ยิ่งประสบการณ์แตกต่างกันมากเท่าไหร่ BFF ก็ยิ่งช่วยได้มากเท่านั้น
• แบ็กเอนด์ที่ใช้ร่วมกันกลายเป็นคอขวด หากทุกการเปลี่ยนแปลงของส่วนหน้าบังคับให้ต้องมีการเจรจาข้ามทีม การแยกการปรับแต่งเฉพาะไคลเอนต์ออกเป็น BFFs สำหรับแต่ละทีมจะช่วยลดภาระการประสานงาน
• คุณต้องการรูปแบบข้อมูลที่เหมาะสมที่สุดสำหรับไคลเอนต์ มือถือต้องการการตอบสนองที่เบาบางและการแคชที่เข้มงวด; เดสก์ท็อปต้องการข้อมูลรวมที่สมบูรณ์ BFF ช่วยให้คุณสามารถปรับแต่งแต่ละสิ่งได้โดยไม่มีข้อจำกัด
• ภาษาที่เหมาะสมกับส่วนหน้าหนึ่งๆ ได้ดีกว่า ทีมสามารถสร้าง BFF ของตนในรันไทม์ที่เหมาะสมกับไคลเอนต์ โดยไม่ขึ้นกับว่า BFF อื่นๆ ใช้ภาษาใด

เมื่อใดที่ไม่ควรใช้ BFF

รูปแบบนี้ไม่ได้มาฟรีๆ และมีกรณีที่ชัดเจนที่มันเพิ่มต้นทุนโดยไม่มีผลตอบแทน:

• คุณมีไคลเอนต์เพียงตัวเดียว หากมีอินเทอร์เฟซเดียว BFF ก็เป็นเพียงการกระโดดพิเศษอีกหนึ่งครั้ง สร้างแบ็กเอนด์ปกติจะดีกว่า
• ไคลเอนต์ของคุณทำการร้องขอแบบเดียวกัน หากเว็บและมือถือต้องการข้อมูลที่เกือบจะเหมือนกันในรูปแบบเดียวกัน BFF ที่แยกกันจะซ้ำซ้อนและไม่มีประโยชน์ ควรสรุปรวมกันจะดีกว่า
• GraphQL แก้ปัญหาการปรับแต่งของคุณได้อยู่แล้ว ด้วย GraphQL ไคลเอนต์แต่ละตัวจะสอบถามฟิลด์ที่ต้องการอย่างแม่นยำจากปลายทางเดียว ซึ่งครอบคลุมปัญหา over-fetching และ under-fetching โดยไม่ต้องมีแบ็กเอนด์เฉพาะไคลเอนต์ หากคุณมีเลเยอร์ GraphQL พร้อมตัวแก้ไขเฉพาะส่วนหน้า (frontend-specific resolvers) การมีชั้น BFF แยกต่างหากมักจะไม่เพิ่มมูลค่า ดู GraphQL คืออะไร เพื่อพิจารณาว่าเหมาะสมหรือไม่ก่อนที่จะเพิ่มชั้น BFF
• เกตเวย์รวมกับไมโครเซอร์วิสก็เพียงพอแล้ว สำหรับระบบที่เรียบง่าย API Gateway ที่อยู่หน้าไมโครเซอร์วิสที่ออกแบบมาอย่างดีสามารถให้ผลลัพธ์ที่ยอมรับได้โดยไม่ต้องมีชั้นบริการเฉพาะไคลเอนต์

ข้อเสียที่ตรงไปตรงมา

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

การซ้ำซ้อนของโค้ด (Code duplication) นี่คือข้อแลกเปลี่ยนที่สำคัญที่สุด และเอกสารของ Microsoft ก็กล่าวถึงเรื่องนี้โดยตรง เมื่อ BFF ทั้งสามตัวจำเป็นต้องเรียกใช้การตรวจสอบการยืนยันตัวตนแบบเดียวกัน หรือจัดรูปแบบวันที่เดียวกันด้วยวิธีเดียวกัน ตรรกะเหล่านั้นมักจะถูกเขียนซ้ำสามครั้ง คุณกำลังแลกเปลี่ยนการซ้ำซ้อนกับการปรับแต่งเฉพาะ การแก้ไขคือระเบียบวินัย: เก็บลอจิกที่ใช้ร่วมกันอย่างแท้จริงไว้ในไลบรารีที่ BFFs อิมพอร์ต และสงวน BFF ไว้สำหรับการปรับแต่งเฉพาะไคลเอนต์เท่านั้น ผลักข้อกังวลข้ามสายงานที่แท้จริง (การยืนยันตัวตน, การจำกัดอัตรา, การตรวจสอบ) ขึ้นไปที่เกตเวย์ แทนที่จะนำมาใช้งานซ้ำในแต่ละ BFF

บริการที่ต้องดูแลจัดการมากขึ้น BFF แต่ละตัวเป็นหน่วยที่สามารถนำไปใช้งานได้อีกหน่วยหนึ่ง ซึ่งมีวงจรชีวิต, ไปป์ไลน์, การหมุนเวียนการโทรตามคำขอ (on-call rotation), และพื้นผิวความปลอดภัยของตัวเอง บริการที่มากขึ้นหมายถึงภาระการปฏิบัติงานที่มากขึ้น

การกระโดดเครือข่ายเพิ่มเติม (An extra network hop) ไคลเอนต์ไม่สามารถสื่อสารกับบริการโดยตรงอีกต่อไป BFF เพิ่มการกระโดดอีกหนึ่งครั้ง และนั่นอาจเพิ่มความล่าช้าได้ โดยปกติแล้วเป็นการแลกเปลี่ยนที่คุ้มค่า เนื่องจาก BFF ช่วยลดการเดินทางไปกลับระหว่างไคลเอนต์กับบริการหลายครั้ง ด้วยการร้องขอจากไคลเอนต์ไปยัง BFF เพียงครั้งเดียว และให้ BFF เรียกใช้บริการต่างๆ พร้อมกันที่อยู่ใกล้กัน แต่นี่คือต้นทุนที่ต้องวัดผล ไม่ใช่การสันนิษฐาน

ความเสี่ยงที่ BFF จะมีขนาดใหญ่เกินไป (bloated) หาก BFF เริ่มให้บริการไคลเอนต์หลายราย หรือดูดซับตรรกะทางธุรกิจที่ควรอยู่ในไมโครเซอร์วิส มันก็จะกลับไปเป็นแบ็กเอนด์ทั่วไปที่คุณพยายามหลีกหนี จงทำให้มันบางเบาเข้าไว้

การรักษาข้อตกลง BFF ให้สอดคล้องกันด้วย Apidog

ส่วนที่ยากในการรัน BFF ในทางปฏิบัติคือเรื่องของข้อตกลง (contracts) BFF แต่ละตัวจะเปิดเผย API ที่ลูกค้าใช้งานเป็นของตัวเอง และยังขึ้นอยู่กับข้อตกลงของไมโครเซอร์วิสที่อยู่เบื้องล่างอีกด้วย นี่คืออินเทอร์เฟซที่เคลื่อนไหวมากมายข้ามทีมที่ดูแลเลเยอร์ต่างกัน และความแตกต่างระหว่างพวกมันคือที่มาของข้อบกพร่องและไคลเอนต์ที่เสียหาย

นี่คือจุดที่ Apidog เข้ากับเวิร์กโฟลว์ Apidog เป็นแพลตฟอร์มสำหรับการออกแบบ API, การทดสอบ, การจำลอง, และเอกสาร ดังนั้นข้อตกลง API ของ BFF แต่ละตัวจึงมีแหล่งข้อมูลเดียวที่ทั้งทีมส่วนหน้าและแบ็กเอนด์สามารถทำงานร่วมกันได้:

• ออกแบบข้อตกลงก่อน กำหนดปลายทาง BFF แต่ละรายการและโครงสร้างคำขอและตอบกลับในตัวออกแบบภาพของ Apidog โดยมี OpenAPI อยู่เบื้องหลัง เพื่อให้รูปแบบที่ไคลเอนต์ใช้งานได้ตกลงกันก่อนที่จะเขียนโค้ด นี่คือ แนวทาง contract-first ที่นำไปใช้กับเลเยอร์ BFF และช่วยให้ ข้อตกลง API ชัดเจน
• จำลองก่อนที่จะมีอยู่จริง ทีมส่วนหน้าสามารถเริ่มสร้างโดยใช้ Apidog smart mock ของ BFF ได้ทันทีที่ข้อตกลงได้รับการอนุมัติ โดยไม่ต้องรอให้ BFF หรือบริการปลายน้ำพร้อม
• ทดสอบข้อตกลง การทดสอบอัตโนมัติและการยืนยันของ Apidog ตรวจสอบว่า BFF แต่ละตัวส่งคืนข้อมูลที่รวมและปรับเปลี่ยนรูปแบบตามที่ไคลเอนต์คาดหวัง และพวกมันเข้ากันได้กับ CI ดังนั้นการเปลี่ยนแปลงปลายน้ำที่ทำให้การตอบกลับของ BFF เสียหายจะถูกตรวจจับได้ตั้งแต่เนิ่นๆ
• จัดทำเอกสารสำหรับทั้งสองฝ่าย Apidog สร้างเอกสารแบบโต้ตอบอัตโนมัติจากข้อตกลง ดังนั้นทีมส่วนหน้าอ่าน API ของ BFF และทีมแบ็กเอนด์ที่เป็นเจ้าของบริการที่อยู่เบื้องล่างจึงใช้แหล่งข้อมูลความจริงเดียวกัน

เพื่อให้ขอบเขตชัดเจน: Apidog ไม่ได้สร้าง, โฮสต์, หรือรัน BFF ของคุณ และไม่ใช่ API gateway มันเป็นที่ที่คุณออกแบบ, จำลอง, ทดสอบ, และจัดทำเอกสารข้อตกลง API ที่แต่ละ BFF อยู่เบื้องหลัง ซึ่งเป็นสิ่งที่ช่วยให้ทีมส่วนหน้าและแบ็กเอนด์ทำงานร่วมกันได้อย่างสอดคล้องกันเมื่อ BFFs พัฒนาขึ้น การปฏิบัติต่อ BFF แต่ละตัว เสมือนเป็นผลิตภัณฑ์ ที่มีข้อตกลงที่มั่นคงและมีเอกสารที่ดีคือสิ่งที่ทำให้รูปแบบนี้ยั่งยืน

คำถามที่พบบ่อย

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

ฉันควรมี BFF กี่ตัว? โดยปกติแล้วคือหนึ่งตัวต่อหนึ่งประสบการณ์ไคลเอนต์ที่แตกต่างกัน: หนึ่งสำหรับเว็บ, หนึ่งสำหรับ iOS, หนึ่งสำหรับ Android, และอื่นๆ ควรรวมสองตัวเข้าด้วยกันเฉพาะเมื่อทีมเดียวเป็นเจ้าของไคลเอนต์ที่มีความต้องการเกือบจะเหมือนกัน แยกออกไปอีกเมื่อ BFF หนึ่งตัวเริ่มสะสมตรรกะเงื่อนไขต่อไคลเอนต์

GraphQL แทนที่รูปแบบ BFF ได้หรือไม่? ทำได้สำหรับส่วนของการปรับแต่งรูปแบบข้อมูล GraphQL ช่วยให้ไคลเอนต์แต่ละตัวร้องขอเฉพาะฟิลด์ที่ต้องการจากปลายทางเดียว ซึ่งครอบคลุมปัญหา over-fetching และ under-fetching โดยไม่ต้องมีแบ็กเอนด์เฉพาะไคลเอนต์ หากคุณมี GraphQL พร้อมตัวแก้ไขเฉพาะส่วนหน้า (frontend-specific resolvers) การมีชั้น BFF แยกต่างหากมักจะเพิ่มมูลค่าน้อย BFFs ยังคงมีประโยชน์เมื่อคุณต้องการการจัดลำดับการทำงานเฉพาะไคลเอนต์, การแปลโปรโตคอล, หรือตัวเลือกการรันไทม์ที่เซิร์ฟเวอร์ GraphQL ที่ใช้ร่วมกันไม่สามารถให้ได้ง่ายๆ

ฉันสามารถใช้ BFF และ API Gateway ร่วมกันได้หรือไม่? ได้ และเป็นเรื่องปกติ API Gateway จัดการข้อกังวลที่ใช้ร่วมกันในไคลเอนต์ทั้งหมด เช่น การยืนยันตัวตน, การจำกัดอัตรา, และการตรวจสอบ, และกำหนดเส้นทางทราฟฟิกไปยัง BFF ที่เหมาะสม BFF แต่ละตัวจัดการสิ่งที่เฉพาะเจาะจงสำหรับไคลเอนต์ของตน พวกมันอยู่ในเลเยอร์ที่แตกต่างกันและมีหน้าที่ที่แตกต่างกัน

ใครควรเป็นเจ้าของ BFF? ทีมส่วนหน้าที่เป็นเจ้าของไคลเอนต์ ความเป็นเจ้าของนี้เป็นหัวใจสำคัญของรูปแบบนี้ ช่วยให้ทีมสามารถเผยแพร่การเปลี่ยนแปลง UI และปลายทางสนับสนุนพร้อมกัน, เลือกสภาพแวดล้อมรันไทม์ของตัวเอง, และดำเนินการโดยไม่ต้องรอคิวของทีมแบ็กเอนด์แยกต่างหาก

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