BFF và API Gateway: Điểm khác biệt và khi nào nên dùng

“BFF vs API Gateway” là một trong những nhầm lẫn phổ biến nhất trong kiến trúc microservices. Trên sơ đồ, cả hai đều nằm trước backend, nhận request từ client và chuyển tiếp đến service phía sau. Nhưng chúng không cạnh tranh với nhau: API Gateway xử lý chính sách chung ở rìa hệ thống, còn Backend for Frontend (BFF) định hình API cho từng trải nghiệm frontend cụ thể.

Dùng thử Apidog ngay hôm nay

Trong thực tế, BFF thường nằm sau hoặc song song với gateway, không thay thế gateway. Nếu nhầm ranh giới này, bạn sẽ dễ đưa xác thực, rate limit hoặc logic frontend-specific vào sai lớp, làm hệ thống khó vận hành và khó mở rộng.

Bài viết này phân biệt rõ từng mẫu thiết kế, khi nào dùng, khi nào dùng cả hai, và cách giữ hợp đồng API rõ ràng cho từng lớp.

API Gateway là gì?

Một API gateway là điểm vào tập trung giữa client và các backend service. Mọi request đi qua gateway trước khi được định tuyến đến service phù hợp.

Gateway xử lý các vấn đề xuyên suốt giống nhau cho mọi client:

• Routing: ánh xạ path hoặc host đến upstream service.
• Authentication / authorization: xác thực token, từ chối request không hợp lệ.
• Rate limiting / throttling: bảo vệ backend khỏi quá tải hoặc lạm dụng.
• Observability: log request, emit metrics, trace request.
• TLS termination, caching, request transformation: xử lý hạ tầng tại một nơi.

Ví dụ trách nhiệm phù hợp với gateway:

Client
  -> API Gateway
      - Validate JWT
      - Apply rate limit
      - Log request
      - Route /orders/* to Order Service
  -> Order Service

Đặc điểm quan trọng: gateway có mục đích chung và thường do nhóm platform hoặc infrastructure sở hữu. Nó không nên chứa logic riêng cho từng UI như “mobile cần ít field hơn web” hoặc “dashboard cần gộp dữ liệu khác”.

Nếu một chính sách phải áp dụng giống nhau cho mọi client, gateway là nơi phù hợp. Để hiểu ranh giới với các công cụ nền tảng rộng hơn, xem thêm Quản lý API vs API gateway.

Backend for Frontend (BFF) là gì?

Backend for Frontend (BFF), được giới thiệu bởi Sam Newman, là backend được thiết kế riêng cho một trải nghiệm frontend.

Thay vì một backend chung phục vụ mọi client, bạn tạo backend theo từng loại trải nghiệm:

Web App     -> Web BFF     -> Microservices
Mobile App  -> Mobile BFF  -> Microservices
Partner App -> Partner BFF -> Microservices

Quy tắc thực tế: một trải nghiệm, một BFF.

• Web có thể có Web BFF.
• Mobile có thể có Mobile BFF.
• iOS và Android có thể dùng chung một BFF nếu chúng có nhu cầu dữ liệu gần giống nhau và cùng một nhóm duy trì.

Mẫu này xuất hiện nhiều trong microservices, nơi một backend dùng chung cho nhiều frontend dễ trở thành điểm nghẽn giống hệ thống nguyên khối.

BFF thường làm các việc sau:

• Aggregation: gọi nhiều service và trả về một response tổng hợp.
• Trimming: loại bỏ field frontend không cần.
• Reshaping: đổi cấu trúc dữ liệu cho phù hợp màn hình.
• Client-specific formatting: tối ưu response cho mobile, web hoặc dashboard.

Ví dụ mobile cần hiển thị màn hình sản phẩm:

Mobile App
  -> Mobile BFF /product-summary/123
      -> Product Service
      -> Inventory Service
      -> Pricing Service
  <- {
       "id": "123",
       "name": "Keyboard",
       "price": 49.99,
       "inStock": true
     }

Nếu không có BFF, mobile có thể phải gọi 3 service riêng, xử lý nhiều payload thừa và tự ghép dữ liệu. BFF gom việc đó lại thành một API phù hợp với màn hình.

BFF là một dạng bộ tổng hợp API, nhưng khác ở chỗ nó phục vụ một frontend cụ thể, không phải một lớp trung lập dùng chung cho tất cả.

Điểm trùng lặp giữa BFF và API Gateway

BFF và gateway dễ bị nhầm vì chúng có một số hành vi giống nhau:

• Cả hai đều nhận request từ client.
• Cả hai đều có thể route request.
• Cả hai đều có thể gọi backend service.
• Cả hai có thể xuất hiện như một “hộp trung gian” trên sơ đồ kiến trúc.

Nhưng sự khác biệt nằm ở mục đích và quyền sở hữu.

Tiêu chí	API Gateway	BFF
Mục tiêu	Chính sách chung	Trải nghiệm frontend cụ thể
Chủ sở hữu	Platform / infrastructure team	Frontend hoặc product team
Phạm vi	Tất cả client	Một client hoặc một nhóm client tương tự
Logic chính	Auth, rate limit, routing, logging	Aggregation, trimming, reshaping
Tần suất thay đổi	Ổn định hơn	Thay đổi theo UI

Ranh giới thực tế:

Nếu trách nhiệm giống nhau cho mọi client -> đặt ở API Gateway.
Nếu trách nhiệm thay đổi theo từng frontend -> đặt ở BFF.

Ví dụ:

• JWT validation: gateway.
• Rate limit theo tenant: gateway.
• Response chỉ gồm field mobile cần: BFF.
• Gộp product + inventory + pricing cho màn hình mobile: BFF.
• Log request chuẩn toàn hệ thống: gateway.

Theo hướng dẫn của Microsoft, các concern xuyên suốt như monitoring, authorization và rate limiting nên được tách khỏi BFF và xử lý bằng gateway hoặc lớp tương đương. BFF chỉ nên chứa logic dành riêng cho client.

BFF và API Gateway hoạt động cùng nhau như thế nào?

Trong hệ thống microservices thực tế, bạn thường chạy cả hai theo lớp:

Client
  -> API Gateway
      -> BFF
          -> Microservice A
          -> Microservice B
          -> Microservice C

Một request điển hình:

1. Mobile app gửi request kèm token.
2. API Gateway xác thực token, áp dụng rate limit, ghi log và route request đến Mobile BFF.
3. Mobile BFF gọi Product Service, Inventory Service và Pricing Service.
4. BFF gộp dữ liệu, loại bỏ field thừa, trả response phù hợp màn hình mobile.
5. Gateway trả response về client.

Ví dụ luồng trách nhiệm:

GET /mobile/products/123

API Gateway:
  - Verify token
  - Enforce rate limit
  - Add trace ID
  - Route to Mobile BFF

Mobile BFF:
  - Fetch product
  - Fetch inventory
  - Fetch price
  - Build mobile-specific response

Mỗi lớp làm một việc rõ ràng:

• Gateway sở hữu chính sách đồng nhất.
• BFF sở hữu hình dạng dữ liệu theo client.
• Frontend team có thể thay đổi BFF mà không phải chỉnh gateway.
• Platform team có thể thay đổi rate limit mà không phải deploy lại BFF.

Cách phân lớp này giống với việc gateway cùng tồn tại với các thành phần khác như bộ cân bằng tải hoặc service mesh. Mỗi lớp xử lý một phần riêng của đường đi request. Đây cũng là tinh thần của kết nối API-led: giao cho mỗi lớp một trách nhiệm rõ ràng.

Bảng quyết định: BFF vs API Gateway

Câu hỏi	API Gateway	BFF
Ai sở hữu?	Platform / infrastructure team	Team frontend sử dụng nó
Phục vụ ai?	Tất cả client	Một frontend cụ thể
Công việc chính	Auth, rate limit, routing, observability	Aggregation, trimming, reshaping
Chạy bao nhiêu cái?	Thường một gateway cho mỗi edge	Một BFF cho mỗi trải nghiệm khác biệt
Mức độ khớp nối	Lỏng, không phụ thuộc client	Chặt, theo thiết kế của client
Tần suất thay đổi	Ổn định hơn	Nhanh, theo roadmap frontend
Nên chứa gì?	Logic giống nhau cho mọi client	Logic riêng cho một client

Checklist nhanh:

[ ] Logic này có áp dụng giống nhau cho web, mobile và partner không?
    -> Có: gateway

[ ] Logic này chỉ tồn tại vì một màn hình hoặc frontend cụ thể cần?
    -> Có: BFF

[ ] Bạn cần cả xác thực tập trung và response riêng cho mobile?
    -> Dùng cả gateway và BFF

Khi nào nên sử dụng API Gateway?

Sử dụng API gateway khi bạn có nhiều service và cần một điểm nhất quán để xử lý:

• Authentication.
• Authorization.
• Rate limiting.
• Routing.
• Logging và tracing.
• TLS termination.
• Caching chung.

Nếu bạn expose nhiều hơn vài service ra client, gateway thường là lớp nên có trước.

Ví dụ không nên để client gọi trực tiếp nhiều service như sau:

Web App -> User Service
Web App -> Order Service
Web App -> Payment Service
Web App -> Notification Service

Thay vào đó:

Web App -> API Gateway -> Services

Gateway giúp bạn không phải lặp lại authentication, logging và rate limiting ở từng service.

Khi nào nên sử dụng BFF?

Sử dụng BFF khi các frontend có nhu cầu dữ liệu khác nhau đáng kể từ cùng backend.

Các dấu hiệu nên cân nhắc BFF:

• Mobile và web cần payload khác nhau.
• Một backend dùng chung liên tục phải thêm logic điều kiện cho từng UI.
• Frontend phải gọi quá nhiều service để dựng một màn hình.
• Client nhận quá nhiều field thừa.
• Team frontend bị chặn vì phải chờ backend chung thay đổi.
• Một API đa năng đã trở thành điểm nghẽn.

Ví dụ response chung quá lớn:

{
  "id": "123",
  "name": "Keyboard",
  "description": "...",
  "manufacturer": "...",
  "warehouseLocations": [...],
  "internalCost": 21.5,
  "pricingRules": [...],
  "auditTrail": [...],
  "seoMetadata": {...}
}

Mobile có thể chỉ cần:

{
  "id": "123",
  "name": "Keyboard",
  "price": 49.99,
  "inStock": true
}

Đây là logic phù hợp với BFF.

Khi nào không nên xây dựng BFF?

Không nên thêm BFF nếu:

• Bạn chỉ có một client.
• Các client có nhu cầu dữ liệu gần giống nhau.
• API hiện tại phục vụ tốt mọi frontend.
• Chi phí vận hành thêm service lớn hơn lợi ích.
• Một lớp GraphQL với resolver phù hợp đã cho phép client lấy chính xác field cần.

BFF không miễn phí. Nó thêm:

• Một network hop.
• Một service cần deploy và monitor.
• Một hợp đồng API mới.
• Khả năng trùng lặp code giữa nhiều BFF.

Nếu một API chung đủ tốt, giữ kiến trúc đơn giản hơn.

Những sai lầm thường gặp

1. Đặt authentication và rate limit vào BFF

Đây là lỗi phổ biến nhất.

Authentication, authorization và rate limiting là concern xuyên suốt. Nếu đặt chúng vào từng BFF, bạn sẽ có nguy cơ lệch chính sách:

Mobile BFF: rate limit 100 req/min
Web BFF: rate limit 500 req/min
Partner BFF: quên validate scope

Kết quả là bảo mật và vận hành không nhất quán.

Cách đúng:

API Gateway:
  - Auth
  - Authorization
  - Rate limit

BFF:
  - Client-specific aggregation
  - Client-specific response shape

2. Để BFF trở thành monolith thứ hai

BFF nên nhỏ và tập trung vào một trải nghiệm. Nếu bạn đưa logic nghiệp vụ dùng chung vào BFF, nó sẽ dần trở thành backend đa năng mới.

Không nên:

Mobile BFF:
  - Pricing rules
  - Order validation
  - Inventory allocation
  - Customer segmentation
  - UI response shaping

Nên:

Pricing Service:
  - Pricing rules

Order Service:
  - Order validation

Inventory Service:
  - Inventory allocation

Mobile BFF:
  - Compose response for mobile screen

3. Dùng gateway như BFF

Một số team nhét transformation theo client vào gateway để tránh tạo BFF. Cách này có thể ổn lúc đầu, nhưng sẽ làm frontend phụ thuộc vào platform team cho mọi thay đổi UI-specific.

Nếu mobile cần đổi response, team mobile phải tạo ticket cho team platform. Đây là dấu hiệu logic đã nằm sai chỗ.

4. Xây BFF quá sớm

Nếu bạn chỉ có một web app và chưa có client khác, BFF có thể là overengineering. Bắt đầu với API chung. Khi xuất hiện client thứ hai có nhu cầu khác biệt rõ ràng, hãy tách BFF.

5. Quên hợp đồng API

Mỗi gateway route và mỗi BFF endpoint đều là API. Chúng cần:

• Contract rõ ràng.
• Test case.
• Mock.
• Documentation.
• Versioning strategy nếu cần.

Nếu bỏ qua contract, BFF “mỏng” sẽ nhanh chóng thành hộp đen chỉ team sở hữu hiểu được. Xem thêm hợp đồng API là gì.

Cách triển khai thực tế

Một cách triển khai đơn giản:

/api/mobile/* -> API Gateway -> Mobile BFF
/api/web/*    -> API Gateway -> Web BFF
/api/admin/*  -> API Gateway -> Admin BFF

Ví dụ contract cho Mobile BFF:

GET /mobile/products/{productId}/summary
Authorization: Bearer <token>

Response:

{
  "id": "123",
  "name": "Keyboard",
  "price": 49.99,
  "currency": "USD",
  "inStock": true
}

BFF có thể gọi các service phía sau:

GET /products/123
GET /inventory/123
GET /pricing/123

Nhưng client chỉ cần biết một endpoint duy nhất:

GET /mobile/products/123/summary

Khi thiết kế, hãy ghi rõ trách nhiệm:

Gateway contract:
  - Public route
  - Auth requirement
  - Rate limit
  - Headers forwarded

BFF contract:
  - Endpoint shape
  - Request parameters
  - Aggregated response schema
  - Error model

Apidog phù hợp ở đâu?

Dù request đi qua API gateway, BFF, hay cả hai, mỗi lớp đều lộ ra một hợp đồng API. Apidog là nơi bạn thiết kế, kiểm thử, giả lập và tài liệu hóa các hợp đồng đó. Nó không xây dựng, lưu trữ hay thay thế gateway hoặc BFF; nó cung cấp một workspace cho các bề mặt API mà chúng expose.

Cụ thể:

• Design: mô hình hóa response tổng hợp của BFF hoặc schema endpoint được route qua gateway theo hướng schema-first, sau đó tạo OpenAPI để frontend và backend cùng phát triển.
• Mock: tạo mock cho BFF để team mobile hoặc web phát triển UI trước khi các service hạ nguồn hoàn tất. Đây là workflow API-first.
• Test: xây dựng test case tự động gọi endpoint phía trước gateway giống client thật, kiểm tra auth, status code và response shape.
• Document: xuất bản tài liệu tương tác cho từng BFF và gateway route để các team tích hợp không phải đọc implementation.

Mẫu thiết kế là quyết định kiến trúc. Hợp đồng API là phần luôn tồn tại. Apidog giúp bạn quản lý phần đó để BFF và gateway luôn được thiết kế, mock, test và document rõ ràng.

Dùng thử Apidog miễn phí để thiết kế và giả lập hợp đồng BFF và gateway trước khi viết backend.

Câu hỏi thường gặp

BFF có phải là một loại API gateway không?

Không. Chúng có thể cùng route và aggregate request, nhưng mục đích khác nhau. BFF được sở hữu bởi frontend team và tối ưu cho một trải nghiệm client. API gateway được sở hữu tập trung và phục vụ mọi client một cách đồng nhất.

Tôi có thể dùng BFF mà không cần API gateway không?

Có, nhưng ở quy mô lớn thường không nên. Nếu không có gateway, mỗi BFF phải tự xử lý các concern như authentication và rate limiting, dễ dẫn đến policy không nhất quán.

Tôi nên có bao nhiêu BFF?

Theo nguyên tắc “một trải nghiệm, một BFF”. Tạo BFF riêng cho frontend khác biệt đáng kể. Các client tương tự, ví dụ iOS và Android do cùng một team duy trì, có thể dùng chung BFF.

BFF có thay thế API gateway không?

Không. Chúng là hai lớp bổ trợ. Gateway thực thi chính sách đồng nhất ở edge. BFF định hình dữ liệu cho client cụ thể phía sau gateway.

Khi nào không nên xây dựng BFF?

Không nên dùng BFF khi chỉ có một client, khi các client có nhu cầu dữ liệu gần giống nhau, hoặc khi một lớp GraphQL với resolver phù hợp đã cho phép client lấy đúng dữ liệu cần.

Authentication và rate limiting nên nằm ở BFF hay gateway?

Nên nằm ở gateway. Đây là concern xuyên suốt cần nhất quán trên mọi client. Đặt chúng trong từng BFF sẽ gây trùng lặp logic và lệch chính sách.