BFF vs API Gateway: ต่างกันอย่างไร และควรใช้ตัวไหนเมื่อไหร่

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

พวกเขาไม่ใช่คู่แข่งกัน Backend for Frontend (BFF) และ API gateway แก้ปัญหาที่แตกต่างกัน ถูกดูแลโดยทีมงานที่แตกต่างกัน และบ่อยครั้งที่ทำงานร่วมกันในระบบเดียวกัน BFF อยู่ด้านหลังหรือเคียงข้างเกตเวย์ ไม่ใช่แทนที่เกตเวย์

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

API Gateway คืออะไร?

API gateway คือจุดเข้าใช้งานส่วนกลางที่อยู่ระหว่างไคลเอ็นต์และบริการแบ็กเอนด์ของคุณ ทุกคำขอจะเข้ามาทางเกตเวย์ ซึ่งจะใช้หลักการที่ใช้ร่วมกันทั้งหมด (cross-cutting concerns) ก่อนที่จะส่งต่อคำขอ

หลักการเหล่านั้นเหมือนกันสำหรับทุกไคลเอ็นต์และทุกบริการ:

• การกำหนดเส้นทาง (Routing): จับคู่พาธที่เข้ามากับบริการปลายน้ำที่ถูกต้อง
• การยืนยันตัวตนและการอนุญาต (Authentication and authorization): ตรวจสอบโทเค็น ปฏิเสธผู้เรียกที่ไม่ได้รับอนุญาต
• การจำกัดอัตรา (Rate limiting) และการควบคุมปริมาณ (throttling): ปกป้องแบ็กเอนด์จากโหลดเกินและการใช้งานในทางที่ผิด
• ความสามารถในการสังเกตการณ์ (Observability): บันทึกคำขอ ส่งเมตริก ติดตามการเรียกข้ามบริการ
• การยุติ TLS (TLS termination), การแคช (caching) และการแปลงคำขอ (request transformation): จัดการส่วนประกอบพื้นฐานทั้งหมดในที่เดียว

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

สิ่งนี้ทำให้เกตเวย์เป็นที่ที่เหมาะสมสำหรับกฎเกณฑ์ระดับองค์กร หากคุณต้องการให้ทุกคำขอได้รับการตรวจสอบสิทธิ์ในวิธีเดียวกัน หรือ API ทุกรายการมีการจำกัดอัตราที่สอดคล้องกัน เกตเวย์จะบังคับใช้สิ่งเหล่านี้โดยที่แต่ละบริการไม่จำเป็นต้องนำตรรกะไปใช้งานซ้ำ สำหรับความแตกต่างกับเครื่องมือแพลตฟอร์มที่กว้างขึ้น โปรดดูที่ API management vs API gateway

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

Backend for Frontend หรือ BFF ซึ่งแนะนำโดย Sam Newman ได้เปลี่ยนแนวคิด แทนที่จะเป็นแบ็กเอนด์อเนกประสงค์เดียวที่ให้บริการแก่ไคลเอ็นต์ทุกประเภท คุณสร้างแบ็กเอนด์หนึ่งตัวสำหรับแต่ละประสบการณ์ผู้ใช้ แอปพลิเคชันเว็บมี Web BFF แอปพลิเคชันมือถือมี Mobile BFF แต่ละ BFF ได้รับการปรับแต่งให้เหมาะกับฟรอนต์เอนด์เพียงหนึ่งเดียว รูปแบบนี้เกิดขึ้นจากการทำงานของไมโครเซอร์วิส ซึ่งแบ็กเอนด์ที่ใช้ร่วมกันเพียงหนึ่งเดียวที่ให้บริการแก่ไคลเอ็นต์จำนวนมากกลายเป็นคอขวดแบบเดียวกับ monolith

กฎง่ายๆ ของ Newman คือ “หนึ่งประสบการณ์, หนึ่ง BFF” ฟรอนต์เอนด์ที่แตกต่างกันอย่างมีนัยสำคัญจะได้ BFF ของตัวเอง; ส่วนฟรอนต์เอนด์ที่คล้ายกัน (เช่น แอปพลิเคชัน iOS และ Android ที่ดูแลโดยทีมเดียวกัน) สามารถใช้ BFF ร่วมกันได้

คุณลักษณะสำคัญในที่นี้คือการเป็นเจ้าของและรูปร่าง BFF “มีการผูกติดอย่างแน่นหนากับประสบการณ์ผู้ใช้ที่เฉพาะเจาะจง และโดยทั่วไปจะได้รับการดูแลโดยทีมเดียวกับส่วนต่อประสานผู้ใช้” ตามคำกล่าวของ Newman ทีมฟรอนต์เอนด์เป็นเจ้าของ BFF ของตน พวกเขาพัฒนาไคลเอ็นต์และแบ็กเอนด์ไปพร้อมกัน โดยไม่ต้องรอให้ทีมแบ็กเอนด์แยกต่างหากอนุมัติทุกการเปลี่ยนแปลง

BFF ทำอะไรจริงๆ? มันปรับรูปร่างข้อมูลสำหรับไคลเอ็นต์หนึ่งๆ:

• การรวมข้อมูล (Aggregation): หน้าจออุปกรณ์มือถือต้องการข้อมูลจากไมโครเซอร์วิส 5 ตัว Mobile BFF จะเรียกทั้ง 5 ตัวและส่งคืนการตอบกลับที่รวมกันเป็นหนึ่งเดียว เพื่อให้โทรศัพท์มีการเดินทางไปกลับเพียงครั้งเดียวแทนที่จะเป็น 5 ครั้ง
• การตัดแต่งและปรับรูปร่าง (Trimming and reshaping): ไคลเอ็นต์มือถือต้องการเพียง 3 ฟิลด์จาก 40 ฟิลด์ BFF จะตัดส่วนที่เหลือออกเพื่อประหยัดแบนด์วิธ
• การจัดรูปแบบเฉพาะไคลเอ็นต์ (Client-specific formatting): แอปพลิเคชันเดสก์ท็อปดึงข้อมูลหลายหน้าพร้อมกันเพื่อมุมมองที่สมบูรณ์; แอปพลิเคชันมือถือดึงข้อมูลทีละหน้าเพื่อความเบา แต่ละ BFF ให้บริการตามรูปแบบของไคลเอ็นต์

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

BFF และ API Gateway มีส่วนทับซ้อนกันตรงไหน

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

การทับซ้อนกันเป็นเรื่องจริงแต่ตื้นเขิน ความแตกต่างอยู่ที่เจตนาและการเป็นเจ้าของ:

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

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

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

BFF และ API Gateway ทำงานร่วมกัน

ในระบบไมโครเซอร์วิสจริง คุณไม่ค่อยเลือกอย่างใดอย่างหนึ่ง คุณใช้ทั้งสองอย่างซ้อนกัน เกตเวย์จะอยู่ขอบสุด ส่วน BFFs จะอยู่ด้านหลัง

การไหลของคำขอทั่วไปมีลักษณะดังนี้:

1. ไคลเอ็นต์มือถือส่งคำขอพร้อมโทเค็นการยืนยันตัวตน
2. API gateway ตรวจสอบโทเค็น บังคับใช้การจำกัดอัตรา บันทึกคำขอเพื่อการสังเกตการณ์ จากนั้นกำหนดเส้นทางไปยัง Mobile BFF
3. Mobile BFF เรียกใช้บริการผลิตภัณฑ์ บริการสินค้าคงคลัง และบริการราคา รวบรวมผลลัพธ์ ตัดแต่งเพย์โหลดให้เหลือเฉพาะที่หน้าจอมือถือต้องการ และส่งคืนการตอบกลับเพียงครั้งเดียว
4. เกตเวย์ส่งการตอบกลับกลับไปยังไคลเอ็นต์

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

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

ความสัมพันธ์แบบเลเยอร์นี้คล้ายกับการที่เกตเวย์อยู่ร่วมกับโครงสร้างพื้นฐานอื่นๆ แทนที่จะมาแทนที่ เกตเวย์ไม่ใช่ตัวจัดสรรโหลด (API gateway vs load balancer) และไม่ใช่ service mesh (service mesh vs API gateway) แต่ละส่วนจัดการชั้นที่แตกต่างกันของเส้นทางคำขอ และ BFF ก็เป็นเพียงอีกหนึ่งชั้นที่แตกต่างกันเท่านั้น นี่คือหลักการเดียวกับที่อยู่เบื้องหลัง API-led connectivity: กำหนดงานที่ชัดเจนให้แต่ละชั้นและให้มันทำแค่นั้น

ตารางการตัดสินใจ: BFF vs API Gateway

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

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

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

ใช้ BFF เมื่อ ไคลเอ็นต์ที่แตกต่างกันมีความต้องการที่แตกต่างกันอย่างมีนัยสำคัญจากแบ็กเอนด์เดียวกัน และ API อเนกประสงค์ที่ใช้ร่วมกันกลายเป็นคอขวด ตัวกระตุ้นทั่วไป ตามแนวทางของ Microsoft:

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

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

ใช้ทั้งสองอย่างเมื่อ คุณกำลังรันไมโครเซอร์วิสในระดับใหญ่: เกตเวย์สำหรับนโยบายที่สอดคล้องกันที่ edge ส่วน BFFs อยู่ด้านหลังเพื่อการปรับรูปร่างเฉพาะไคลเอ็นต์ นี่คือสถานะสุดท้ายทั่วไป ไม่ใช่สิ่งแปลกประหลาด

ข้อผิดพลาดทั่วไป

การใส่การยืนยันตัวตนและการจำกัดอัตราใน BFF นี่คือข้อผิดพลาดหลัก หลักการที่ใช้ร่วมกันทั้งหมด (Cross-cutting concerns) ควรอยู่ในเกตเวย์ การทำซ้ำสิ่งเหล่านี้ใน BFFs ต่างๆ จะทำให้เกิดความไม่สอดคล้องกัน: Mobile BFF บังคับใช้นโยบายหนึ่ง, Web BFF อีกนโยบายหนึ่ง และท่าทีความปลอดภัยของคุณก็ไม่สอดคล้องกันโดยไม่ได้ตั้งใจ

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

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

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

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

Apidog เข้ามามีบทบาทอย่างไร

ไม่ว่าคำขอจะไหลผ่าน API gateway, BFF หรือทั้งสองอย่าง แต่ละเลเยอร์จะเปิดเผยสัญญา API Apidog คือที่ที่คุณออกแบบ ทดสอบ จำลอง และจัดทำเอกสารสัญญาเหล่านั้น ไม่ได้สร้าง โฮสต์ หรือแทนที่เกตเวย์หรือ BFF แต่ให้พื้นที่ทำงานเดียวสำหรับส่วนต่อประสาน API ที่พวกมันเปิดเผย

โดยเฉพาะอย่างยิ่ง:

• ออกแบบ (Design): สร้างแบบจำลองการตอบสนองที่รวบรวมของ BFF หรือโครงสร้างปลายทางที่กำหนดเส้นทางของเกตเวย์โดยใช้ Schema-First ใน Visual Designer จากนั้นสร้าง OpenAPI สำหรับทั้งทีมฟรอนต์เอนด์และแบ็กเอนด์ของคุณเพื่อใช้ในการพัฒนา
• จำลอง (Mock): สร้าง Mock ของ BFF แบบอัจฉริยะเพื่อให้ทีมมือถือสามารถพัฒนาหน้าจอของตนได้ก่อนที่บริการปลายน้ำของ BFF จะมีอยู่จริง นี่คือกระบวนการทำงานแบบ API-First ที่ทำให้การทำงานร่วมกันของฟรอนต์เอนด์และแบ็กเอนด์เป็นไปได้
• ทดสอบ (Test): สร้างสถานการณ์การทดสอบอัตโนมัติที่เรียกใช้ปลายทางที่อยู่ด้านหน้าเกตเวย์เหมือนกับที่ไคลเอ็นต์จริงจะทำ ตรวจสอบการยืนยันตัวตน, รหัสสถานะ และรูปร่างของเพย์โหลดที่รวมกัน
• จัดทำเอกสาร (Document): เผยแพร่เอกสารแบบโต้ตอบสำหรับแต่ละ BFF และเส้นทางเกตเวย์ เพื่อให้ทีมผู้ใช้งานทุกคนทราบสัญญาโดยไม่ต้องอ่านการใช้งานจริง

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

ทดลองใช้ Apidog ฟรี เพื่อออกแบบและจำลองสัญญา BFF และเกตเวย์ของคุณ ก่อนที่คุณจะเขียนโค้ดแบ็กเอนด์แม้แต่บรรทัดเดียว

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

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

ฉันสามารถใช้ BFF โดยไม่มี API gateway ได้หรือไม่? ได้ แต่คุณไม่ควรทำเมื่อขยายขนาด โดยไม่มีเกตเวย์ แต่ละ BFF จะต้องนำหลักการที่ใช้ร่วมกันทั้งหมด (cross-cutting concerns) เช่น การยืนยันตัวตนและการจำกัดอัตรา กลับมาใช้ใหม่ ซึ่งนำไปสู่ความไม่สอดคล้องกัน เกตเวย์รวมศูนย์สิ่งเหล่านั้นเพื่อให้แต่ละ BFF จัดการการปรับรูปร่างเฉพาะไคลเอ็นต์เท่านั้น

ฉันควรมี BFF กี่ตัว? ทำตามกฎของ Sam Newman ที่ว่า “หนึ่งประสบการณ์, หนึ่ง BFF” สร้าง BFF แยกต่างหากสำหรับฟรอนต์เอนด์แต่ละอันที่แตกต่างกันอย่างมีนัยสำคัญ ไคลเอ็นต์ที่คล้ายกันซึ่งดูแลโดยทีมเดียวกัน เช่น แอปพลิเคชัน iOS และ Android สามารถใช้ BFF ร่วมกันได้

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

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

การยืนยันตัวตนและการจำกัดอัตราควรอยู่ใน BFF หรือเกตเวย์? ในเกตเวย์ สิ่งเหล่านี้เป็นหลักการที่ใช้ร่วมกันทั้งหมด (cross-cutting concerns) ที่ควรสอดคล้องกันสำหรับไคลเอ็นต์ทั้งหมด การใส่สิ่งเหล่านี้ใน BFF จะเป็นการทำซ้ำตรรกะในทุก BFF และนำไปสู่ความไม่สอดคล้องกันของนโยบาย