API gateway vs BFF cho client web và mobile: các đánh đổi

Vấn đề: một backend, nhiều client, nhu cầu thay đổi

Bắt đầu thường đơn giản: một backend mở một tập các endpoint, và cả web app lẫn mobile app đều gọi chúng. Nhìn thì có vẻ hiệu quả vì chỉ có một nơi để thêm tính năng, sửa lỗi và áp luật.

Rồi thực tế xuất hiện. Giao diện web thường cần các màn hình dày dữ liệu, bộ lọc, xuất dữ liệu và hành động admin. Mobile thường cần ít trường hơn, màn hình nhanh hơn, luồng thân thiện với offline và chú ý đến pin và dữ liệu. Ngay cả khi tính năng "giống nhau", kiểu API phù hợp cho từng client hiếm khi giống hệt.

Dần dần, các endpoint lệch nhau. Team web thêm trường cho một view bảng mới. Mobile muốn loại bỏ payload nặng và gộp nhiều lần gọi thành một. Ai đó thêm tham số "chỉ cho iOS". Người khác tái sử dụng một endpoint admin nội bộ trong app công khai vì nó "đã có sẵn". Điều bắt đầu là một API sạch giờ thành tập hợp của các thỏa hiệp.

Rủi ro hiện ra nhanh:

• Thay đổi phá vỡ khi một client ra nhanh hơn client khác
• Ứng dụng chậm hơn do payload lớn hoặc quá nhiều lần gọi
• Mã backend phức tạp hơn khi mọi endpoint cố gắng phục vụ mọi client
• Lộ dữ liệu vô tình khi trường nội bộ hoặc hành động admin chui vào API công khai
• Phiên bản hóa đau đớn vì các "thay đổi nhỏ" lại không nhỏ đối với client cũ

Đây là mâu thuẫn cốt lõi đằng sau cuộc thảo luận API gateway vs BFF. Bạn muốn API công khai ổn định để mobile và web dựa vào, đồng thời cho mỗi client không gian để phát triển theo nhịp riêng.

API gateway và BFF: là gì (và không phải là gì)

API gateway là cửa trước cho API của bạn. Client gọi gateway, và gateway định tuyến tới service phù hợp. Nó thường xử lý các mối quan tâm chung bạn không muốn lặp ở nhiều nơi, như kiểm tra xác thực, giới hạn tần suất, ghi log yêu cầu, và định hình yêu cầu cơ bản.

Backend-for-frontend (BFF) là một backend nhỏ xây cho một client cụ thể hoặc nhóm client, như "web" và "mobile". Client gọi BFF của nó, và BFF gọi các service phía dưới. Ý tưởng chính là tập trung: BFF được phép nói ngôn ngữ của client (màn hình, luồng, payload), ngay cả khi các service lõi vẫn chung chung hơn.

Những gì hai mô hình này không phải: không phải thay thế cho dịch vụ miền tốt hay mô hình dữ liệu sạch. Các service lõi, cơ sở dữ liệu và quy tắc nghiệp vụ của bạn nên là nguồn chân lý. Gateway hoặc BFF không nên biến thành một khối logic nghiệp vụ lớn dần thành backend thực sự của bạn.

Cách phân biệt đơn giản:

• Gateway: một điểm vào chung, mối quan tâm chia sẻ, định tuyến và bảo vệ
• BFF: API theo client, giảm công việc cho client và che giấu sự phức tạp nội bộ

Bạn cũng có thể kết hợp cả hai. Một thiết lập phổ biến là gateway làm edge công khai, sau đó các BFF riêng phía sau cho web và mobile. Gateway xử lý bảo mật ngoài cùng và luật traffic, trong khi mỗi BFF định hình endpoint và phản hồi cho client của nó.

Đường đi yêu cầu thay đổi thế nào theo từng mô hình

Khác biệt lớn nhất giữa API gateway và BFF là bạn đặt logic "cửa trước" ở đâu: định tuyến, kiểm tra xác thực và định hình phản hồi.

Với API gateway, client thường nói chuyện với một điểm vào chung. Gateway chuyển tiếp yêu cầu tới các service nội bộ, thường làm các tác vụ cơ bản như xác thực token, giới hạn tần suất và định tuyến theo đường dẫn.

Với BFF, mỗi loại client (web, iOS, Android) gọi một backend được xây riêng cho nó. BFF đó gọi các service nội bộ và trả về phản hồi được tùy chỉnh theo màn hình và giới hạn của client.

Cách hình dung đơn giản về đường đi:

• Đường đi API gateway: Client -> Gateway -> Service(s) -> Phản hồi
• Đường đi BFF: Client -> BFF (web hoặc mobile) -> Service(s) -> Phản hồi

Quyền sở hữu thường cũng dịch chuyển. Một team nền tảng hoặc hạ tầng thường quản lý gateway vì nó ảnh hưởng tới mọi team và mọi service. Một feature team thường sở hữu BFF vì nó đi theo UI và chu kỳ phát hành của nó.

Luồng xác thực thường như sau: client gửi token, lớp edge (gateway hoặc BFF) xác thực nó hoặc chuyển sang service auth, rồi truyền thông tin định danh (user id, roles) xuống các service. Sự khác biệt là bạn áp luật client ở đâu. Với gateway, các chính sách thường chung và nhất quán giữa các client. Với BFF, bạn có thể thêm định hình theo client, như trả payload nhỏ hơn cho mobile hoặc gộp nhiều cuộc gọi thành một trả về cho mạng chậm.

Bước định hình này là nơi BFF tỏa sáng, nhưng đồng nghĩa với nhiều thành phần hơn để deploy và giữ đồng bộ.

Tách biệt an toàn endpoint công khai và nội bộ

Endpoint công khai là bất kỳ route API nào web app, mobile app, đối tác hoặc bên thứ ba có thể gọi. Hãy coi nó là môi trường thù địch theo mặc định, vì bạn không kiểm soát mạng hay mã client gọi tới.

Endpoint nội bộ là dành cho traffic service-to-service bên trong hệ thống. Nó có thể thay đổi nhanh hơn, giả định nhiều ngữ cảnh hơn và tiết lộ dữ liệu phong phú hơn, nhưng không bao giờ được truy cập trực tiếp từ Internet công cộng.

Với API gateway, sự tách biệt thường rõ ràng và dễ lý giải: chỉ gateway được phơi ra, và nó quyết định route công khai nào tồn tại. Mọi thứ phía sau giữ ở chế độ riêng tư. Bạn có thể giữ API service nội bộ biểu đạt hơn, trong khi gateway thực thi một bề mặt nhỏ hơn và an toàn hơn.

Với mô hình BFF, sự tách biệt thiên về ranh giới sản phẩm. Mỗi client (web, iOS, Android) chỉ nói chuyện với BFF của nó, và BFF gọi các service nội bộ. Điều này cho phép bạn che giấu sự phức tạp nội bộ: BFF có thể gọi ba service, gộp kết quả và phơi ra một phản hồi đơn giản phù hợp với nhu cầu client.

Sự tách biệt chỉ an toàn nếu bạn thêm các điều khiển thực tế:

• Phân quyền cụ thể: roles và scopes theo route, không chỉ một công tắc "đã đăng nhập"
• Giới hạn tần suất theo user, token và IP cho endpoint công khai
• Lọc payload: chỉ trả những gì client cần, loại bỏ ID nội bộ, thông tin debug và trường chỉ dành cho admin
• Danh sách cho phép rõ ràng: endpoint nào công khai, endpoint nào chỉ nội bộ

Ví dụ: mobile cần màn hình "My Orders". BFF có thể phơi /orders chỉ với trạng thái đơn và tổng tiền, trong khi service order nội bộ giữ chi tiết phân tích chi phí và cờ gian lận ở chế độ riêng tư.

Versioning: cái gì dễ hơn và cái gì khó hơn

Đau đớn với versioning thường xuất hiện khi web và mobile chạy với tốc độ khác nhau. Team web có thể deploy và rollback trong vài giờ. Mobile có thể mất ngày hoặc tuần vì duyệt app store và người dùng không cập nhật. Khoảng cách này là nơi quyết định API gateway vs BFF trở nên thực tế.

Với API gateway, bạn có thể đặt version ở một cửa trước (ví dụ, /v1/..., /v2/...). Điều này dễ giải thích và dễ định tuyến. Nhược điểm là gateway có thể biến thành bảo tàng phiên bản nếu nhiều client và tích hợp đối tác dính chặt vào các phiên bản cũ. Bạn sẽ phải hỗ trợ các dạng dữ liệu cũ lâu hơn.

Với BFF, versioning thường là "theo client". Mobile BFF có thể giữ hợp đồng cũ trong khi web BFF tiến nhanh, ngay cả khi cả hai gọi cùng service nội bộ. Điều đó thường giảm áp lực phải duy trì phiên bản công khai mãi mãi. Đổi lại, bạn có nhiều quyết định phiên bản để quản lý và deploy hơn.

Versioning trong services cũng có thể hoạt động, nhưng nó đẩy các thay đổi do client kéo sâu vào hệ thống. Nó cũng có thể làm code nội bộ khó đọc hơn vì logic service bắt đầu phân nhánh theo phiên bản client.

Thay đổi không phá vỡ là bạn đồng minh: thêm trường tuỳ chọn, thêm endpoint mới, hoặc chấp nhận trường input thừa. Thay đổi phá vỡ bao gồm đổi tên trường, đổi kiểu (chuỗi sang số) hoặc xóa endpoint.

Deprecation hiệu quả nhất khi được lên kế hoạch:

• Đặt ngày kết thúc rõ ràng và thông báo sớm
• Theo dõi việc sử dụng phiên bản cũ (logs, metrics) và quan sát người dùng sót lại
• Rollout cập nhật client trước (đặc biệt mobile), rồi mới gỡ đường dẫn cũ
• Trả về thông báo lỗi rõ ràng khi phiên bản cũ bị chặn

Hiệu năng: độ trễ, kích thước payload và số lần gọi

Hiệu năng trong setup API gateway vs BFF chủ yếu là một sự đánh đổi: một bước trung gian thêm trong hệ thống của bạn so với ít bước hơn trên mạng từ client. Tùy chọn nhanh nhất thường là cái giảm thời gian mạng chậm, ngay cả khi nó thêm một bước xử lý nhỏ ở server.

BFF thường thắng khi client nếu không sẽ phải thực hiện nhiều lần gọi. Thay vì web và mobile gọi năm endpoint rồi ghép kết quả trên thiết bị, BFF có thể lấy dữ liệu cần thiết phía server và trả về một phản hồi. Điều đó thường giảm tổng độ trễ cho mobile vì mạng di động thêm độ trễ cho mỗi yêu cầu.

Các lợi ích hiệu năng phổ biến từ gateway hoặc BFF:

• Tổng hợp: gộp dữ liệu từ nhiều service vào một phản hồi
• Caching thông minh: cache ở edge hoặc ở BFF cho màn hình đọc nhiều
• Payload nhỏ hơn: trả chỉ các trường màn hình cần
• Ít round trip hơn: giảm hành vi chatty của client
• Nén và timeout nhất quán: áp mặc định ở một nơi

Nhưng mẫu này cũng có thể gây hại. Mỗi lớp thêm vào nghĩa là thêm công việc CPU và thêm nơi để chờ. Nếu bạn nhân bản cùng logic tổng hợp cho web và mobile, bạn có thể nhân đôi công việc và tạo hành vi không nhất quán. Over-fetching là tổn thất thường gặp: một endpoint chung cố gắng thoả mãn mọi màn hình có thể trả về payload lớn lãng phí thời gian và băng thông.

Thực tế mobile làm những đánh đổi này rõ rệt hơn. Mạng chập chờn nghĩa là retry và timeout là bình thường, và mỗi cuộc gọi thêm làm hao pin. Cold starts cũng quan trọng: nếu app cần nhiều yêu cầu trước khi màn hình đầu tiên sử dụng được, người dùng sẽ cảm nhận điều đó.

Quy tắc thực tế: tối ưu cho ít yêu cầu client trước, sau đó tối ưu bước trung gian thêm vào.

Cách đánh giá thiết kế nhanh

Nếu một màn hình cần hơn 2-3 cuộc gọi tuần tự, hãy cân nhắc tổng hợp. Nếu phản hồi lớn và phần lớn không dùng, hãy cân nhắc tách endpoint hoặc dùng BFF theo client.

Vận hành: triển khai, giám sát và scale

Với API gateway vs BFF, câu hỏi vận hành lớn là bạn chấp nhận bao nhiêu thành phần động để chạy và hỗ trợ. Gateway thường trở thành hạ tầng chia sẻ cho nhiều team và client. BFF thường là service nhỏ hơn, nhưng bạn có thể có một cho mỗi client (web, iOS, Android, partner), làm tăng tải release và on-call.

Về kiểm thử và phát hành, gateway có thể an toàn hơn khi bạn chủ yếu cần routing, auth và giới hạn tần suất. Thay đổi tập trung, nên một sai sót có thể ảnh hưởng mọi người. BFF giảm phạm vi ảnh hưởng vì thay đổi chỉ deploy lên BFF web, không phải mobile. Đổi lại, bạn có nhiều pipeline hơn để duy trì và nhiều phiên bản cùng chạy.

Để quan sát, bạn cần thấy một request người dùng đơn qua các lớp, đặc biệt khi một cuộc gọi mobile kích hoạt nhiều cuộc gọi backend.

• Sử dụng correlation ID và truyền nó qua gateway, BFF và log backend
• Bắt trace để thấy thời gian tiêu ở đâu (gateway, BFF, service phía sau)
• Giữ log có cấu trúc (client, endpoint, mã trạng thái, latency, kích thước payload)
• Theo dõi vài chỉ số chính cho mỗi endpoint: tỷ lệ lỗi, p95 latency, throughput

Scale cũng khác. Gateway là điểm nghẽn chia sẻ: nó phải xử lý spike và endpoint nóng mà không thành nút thắt. BFF cho phép scale theo client, hữu ích khi traffic web nhảy mạnh trong giờ làm việc còn mobile ổn định.

Trong sự cố, lỗi có thể "dịch chuyển" tuỳ theo mô hình. Với gateway, lỗi thường hiện dưới dạng 5xx lan rộng hoặc lỗi auth. Với BFF, sự cố có thể cô lập vào tính năng của một client. Hãy làm runbook rõ ràng nơi cần kiểm tra trước, và giữ hành vi dự phòng đơn giản (ví dụ, trả phản hồi rút gọn thay vì timeout).

Cách chọn: một quá trình quyết định từng bước đơn giản

Chọn giữa API gateway và BFF ít liên quan tới lý thuyết, mà là về những gì client cần hàng ngày.

Quy trình quyết định thực tế

1. Bắt đầu từ client, không phải server. Liệt kê mọi client bạn hỗ trợ (web app, iOS, Android, API đối tác, admin nội bộ) và ghi lại mỗi màn hình chính cần gì. Nếu cùng view "Customer details" cần trường khác nhau và cách gọi khác nhau giữa client, đó là tín hiệu mạnh cho việc định hình theo client.

2. Vẽ hiện trạng. Lấy các endpoint hiện có và đánh dấu cái nào dùng chung (hoạt động miền lõi như orders, payments, users) so với cái nào định hình phục vụ presentation (tóm tắt dashboard, payload "home screen" gộp). Các phần dùng chung thuộc về backend lõi. Các phần định hình cho presentation thường hợp hơn ở BFF.

3. Quyết nơi đặt logic định hình và quy tắc. Nếu bạn chủ yếu cần routing, auth, giới hạn tần suất, caching và phơi bày an toàn giữa public vs internal, gateway là chỗ tự nhiên. Nếu bạn cần tổng hợp thực thụ (gọi nhiều service, biến sáu gọi thành một, payload khác nhau theo app), đặt logic đó trong BFF để nó dễ kiểm thử và dễ đọc.

4. Chọn quy tắc versioning và deprecation mà bạn thực sự có thể tuân theo. Ví dụ: "Không thay đổi phá vỡ nếu không có phiên bản mới, và mọi trường bị deprecate tồn tại 90 ngày." Với cách chỉ gateway, bạn có thể version bề mặt công khai và dịch phía sau. Với BFF, thường giữ API lõi ổn định và version chỉ endpoint BFF theo client.

5. Lên kế hoạch rollout và đo lường. Trước khi thay đổi, ghi lại chỉ số nền: p95 latency, số cuộc gọi mỗi màn hình, kích thước payload và tỷ lệ lỗi. Roll out nhỏ trước, so sánh trước và sau rồi mở rộng.

Ví dụ đơn giản: nếu mobile release hàng tháng nhưng portal web ship hàng ngày, một mobile BFF nhỏ có thể bảo vệ app khỏi thay đổi backend thường xuyên trong khi web vẫn tiến nhanh.

Ví dụ: portal web + app mobile với tốc độ phát hành khác nhau

Hình dung một công ty có portal khách hàng trên web và app field trên mobile. Cả hai cần cùng dữ liệu lõi: customers, jobs, invoices, messages. Portal thay đổi hàng tuần. Mobile cập nhật chậm hơn vì phải qua duyệt store và cần hoạt động tốt khi tín hiệu yếu.

Đau đớn xuất hiện nhanh. Người dùng mobile muốn phản hồi gọn, ít cuộc gọi và luồng hỗ trợ offline (ví dụ, tải xuống jobs của ngày một lần rồi sync sau). Portal web ổn với nhiều cuộc gọi và màn hình giàu dữ liệu vì luôn online và dễ cập nhật.

Lựa chọn A: gateway trước các service ổn định

Chọn gateway-first giữ service backend phần lớn không thay đổi. Gateway xử lý xác thực, định tuyến và chỉnh sửa nhỏ như header, giới hạn tần suất và ánh xạ trường đơn giản.

Versioning chủ yếu ở cấp service API. Điều này tốt: ít thành phần động. Nhưng cũng có nghĩa thay đổi dành riêng cho mobile thường khiến bạn đi tới các phiên bản lớn như /v2 vì endpoint chung.

Phơi bày endpoint rõ ràng nếu bạn coi gateway là cửa công cộng duy nhất. Các endpoint nội bộ giữ phía sau, nhưng bạn phải nghiêm ngặt về điều gì gateway được phép gọi và phơi ra.

Lựa chọn B: mobile BFF nói "ngôn ngữ" mobile

Với mobile BFF, app mobile gọi tới các endpoint thiết kế cho màn hình mobile và luồng sync. BFF có thể tổng hợp dữ liệu (chi tiết job + customer + message gần nhất), cắt bớt trường và trả một payload phù hợp với nhu cầu app.

Những thay đổi:

• Versioning dễ hơn theo client: bạn có thể version mobile BFF mà không ép portal web phải thay đổi
• Hiệu năng thường cải thiện cho mobile: ít round trip và phản hồi nhỏ hơn
• Tách biệt public vs internal rõ hơn: BFF công khai gọi các service nội bộ không bao giờ cần phơi ra

Sai lầm và bẫy thường gặp

Bẫy lớn nhất trong cuộc tranh luận API gateway vs BFF là biến gateway thành một backend nhỏ. Gateway tốt cho routing, auth, giới hạn tần suất và định hình yêu cầu đơn giản. Khi bạn nhồi nhét quy tắc nghiệp vụ vào đó, bạn có logic ẩn khó kiểm thử, khó debug và dễ phá vỡ khi đổi config.

BFF có thể sai theo chiều ngược lại: team tạo một BFF cho mỗi màn hình hoặc mỗi feature, và việc bảo trì bùng nổ. Một BFF thường nên tương ứng với loại client (web, iOS, Android) hoặc một khu vực sản phẩm rõ ràng, không phải mọi view UI. Nếu không, bạn sẽ nhân bản quy tắc ở nhiều nơi, và versioning trở thành công việc toàn thời gian.

Lỗi versioning thường đến từ hai cực. Nếu bạn version mọi thứ ngay từ đầu, bạn đóng băng API quá sớm và giữ các biến thể cũ sống mãi. Nếu bạn không version bao giờ, bạn cuối cùng sẽ đẩy thay đổi phá vỡ mà không có ý định. Một quy tắc đơn giản hiệu quả: không version cho các thay đổi bổ sung nhỏ, nhưng version khi bạn xóa thứ gì đó hoặc đổi ý nghĩa.

Public vs internal là nơi các team dễ bị thương. Phơi service nội bộ trực tiếp ra Internet (dù là "tạm thời") biến mọi thay đổi nội bộ thành khả năng gây outage hoặc sự cố bảo mật. Giữ ranh giới rõ: chỉ gateway hoặc BFF là công khai, service nội bộ giữ riêng tư.

Vấn đề hiệu năng thường do tự gây ra: payload quá lớn, quá nhiều round trip, và không có ngân sách cho độ trễ. Ví dụ: mobile chỉ cần trạng thái đơn và tổng tiền, nhưng lại nhận cả đối tượng order đầy đủ với từng line item và trường audit, làm mỗi yêu cầu chậm trên mạng di động.

Dấu hiệu cảnh báo:

• Config gateway tham chiếu các khái niệm nghiệp vụ như "điều kiện hoàn tiền" hoặc "quy tắc VIP"
• Số lượng BFF tăng nhanh hơn số client chúng phục vụ
• Bạn không thể giải thích chiến lược versioning trong một câu
• Endpoint service nội bộ có thể truy cập từ Internet công cộng
• Phản hồi ngày càng lớn vì "có thể hữu ích sau này"

Checklist nhanh và bước tiếp theo

Nếu bạn đang lưỡng lự giữa API gateway và BFF, hãy tập trung vào thứ sẽ bị phá vỡ trước trong thực tế: phát hành, payload và ranh giới an ninh.

Checklist nhanh

Nếu bạn trả lời "không" cho nhiều mục dưới đây, thiết lập hiện tại có thể gây hại khi client của bạn phát triển:

• Bạn có thể thay đổi một service backend mà không buộc mọi client phải cập nhật trong cùng tuần không?
• Có ranh giới rõ ràng giữa endpoint công khai (an toàn cho Internet) và endpoint nội bộ (chỉ cho hệ thống đáng tin)?
• Web và mobile chỉ nhận những gì họ cần (không nhận một phản hồi "kitchen sink" lớn)?
• Bạn có thể triển khai dần (tỷ lệ phần trăm nhỏ trước) và thấy lỗi, latency và traffic bất thường nhanh không?
• Bạn biết ai sở hữu hợp đồng cho mỗi endpoint và ai phê duyệt thay đổi phá vỡ không?

Bước tiếp theo

Biến các trả lời thành một kế hoạch. Mục tiêu không phải kiến trúc hoàn hảo, mà là ít ngạc nhiên hơn khi deploy.

Viết hợp đồng API bằng ngôn ngữ đơn giản (input, output, mã lỗi, điều gì được phép thay đổi). Chọn mô hình sở hữu: ai chịu trách nhiệm về nhu cầu client (web/mobile) và ai sở hữu service miền lõi. Quyết nơi versioning nằm (theo client hay tập trung) và đặt quy tắc deprecation bạn sẽ tuân theo.

Thêm giám sát cơ bản trước khi refactor lớn: tần suất yêu cầu, p95 latency, tỷ lệ lỗi và các endpoint có kích thước payload lớn nhất. Thử nghiệm các luồng client rủi ro nhất trước.

Nếu bạn xây bằng AppMaster (appmaster.io), một cách thực tế là giữ logic nghiệp vụ lõi và mô hình dữ liệu trong backend được sinh, rồi chỉ thêm một lớp gateway hoặc BFF mỏng khi client thực sự cần định hình payload hoặc cô lập phát hành.

Nếu checklist khó trả lời, coi đó là tín hiệu để đơn giản hoá hợp đồng và thắt chặt ranh giới public vs internal trước khi thêm endpoint.