Chúng ta bắt đầu với một hệ thống hiện có dạng điển hình như sau:

Rồi một ngày đẹp trời chúng ta có thêm yêu cầu hãy xây dựng bản mobile cho web client. Lúc này một loạt suy nghĩ hiện lên trong đầu. Chúng ta nên làm gì, xây dựng app mobile và sử dụng lại Web API sẵn có. Hay tạo một loạt các Mobile API khác và tích hợp vào hệ thống hiện có. Sau một hồi suy nghĩ ta quyết định kiến trúc như sau:

Rồi biết đâu một ngày chúng ta lại có yêu cầu tích hợp thêm client bên thứ 3 nào đó. Hoặc client của một bên khách hàng đối tác. Lúc này ý tưởng của chúng ta sẽ sử dụng kiến trúc “general purpose backend server-side” và nó sẽ như thế này:

Cách tiếp cận này có khá nhiều ưu điểm như:

• Dễ triển khai: Tiết kiệm được thời gian và chi phí ban đầu, tái sử dụng các tính năng dùng chung một cách đơn giản.
• Dễ định tuyến: Cách tiếp cận này giúp định tuyến các request từ client đến các tài nguyên của server diễn ra xuyên suốt, đảm bảo security, authentication, cache. Điều này có thể làm giảm độ trễ và tài nguyên của server.

Đi kèm với ưu điểm thì có nhược điểm sau:

• Sự khác biệt: Giữa các nền tảng (mobile, client, …) đã có những khác biệt, ngoài ra những logic được thiết kế cho từng nền tảng cũng khác nhau. Ví dụ: lượng dữ liệu hiển thị trên màn hình, kích thước màn hình, dung lượng bộ nhớ,… của điện thoại sẽ ít hơn trên web client. Sự khác biệt này có thể dẫn tới việc sửa đổi một số nền tảng mà vẫn phải giữ nền tảng kia không thay đổi. Khi chúng ta cần sửa một đầu API cho một client nào đó, chúng ta cần đảm bảo không ảnh hưởng đến các client hay nền tảng khác.
• Sự tắc nghẽn: Khi có quá nhiều yêu cầu thay đổi API lúc này hiện tượng thắt cổ chai “Bottleneck” sẽ xảy ra trên cùng một cấu trúc code. 

Vậy làm gì để giải quyết bài toán trên, được giới thiệu lần đầu tiên bởi Phil Calcado tại SoundCloud, mô hình Backend for frontend (BFF) gợi ý việc tạo một dịch vụ backend tùy chỉnh được thiết kế riêng cho từng nền tảng client. Vậy chúng ta cùng tìm hiểu BFF trong bài viết ngày hôm nay.

1. Backend for Frontend (BFF) Pattern là cái gì?

Thế BFF là cái gì? BFF là một phương pháp thiết kế kiến ​​trúc biến thể từ Api gateway trong đó các dịch vụ backend riêng biệt được tạo ra dành riêng cho các ứng dụng frontend khác nhau, giống như web, mobile hoặc các client khác. Thay vì một backend duy nhất cố gắng đáp ứng mọi nền tảng, BFF cho phép mỗi client có một backend tùy chỉnh đáp ứng các nhu cầu cụ thể của mình. 

2. Tại sao sử dụng Backend for Frontend Pattern?

Mô hình BFF thường được sử dụng khi xây dựng kiến ​​trúc vì một số lý do sau:

• Khả năng thích ứng với các yêu cầu của nền tảng: Mô hình BFF cho phép developers tạo ra các backend đáp ứng các yêu cầu, định dạng dữ liệu và mô hình tương tác riêng của từng nền tảng client, mang lại trải nghiệm người dùng tốt hơn và sử dụng tài nguyên hiệu quả hơn.
• Tách biệt các mối quan tâm: Bằng cách phân công nhiệm vụ tổng hợp và chuyển đổi dữ liệu cho backend, mô hình BFF thúc đẩy sự tách biệt rõ ràng các mối quan tâm và trách nhiệm giữa frontend và backend.
• Tính linh hoạt và khả năng bảo trì: Mô hình BFF cho phép phát triển, triển khai và mở rộng độc lập các service backend cho từng nền tảng client, thúc đẩy khả năng thích ứng nhanh hơn với các yêu cầu thay đổi mà không ảnh hưởng đến các nền tảng hoặc service khác.
• Hiệu suất được tối ưu hóa: Bằng cách cung cấp một backend chuyên dụng cho mỗi frontend, mô hình BFF có thể tối ưu hóa việc tổng hợp, chuyển đổi và cache dữ liệu, giúp giảm độ trễ, giảm kích thước payload và hiệu suất tổng thể tốt hơn.
• Bảo mật được cải thiện: Bằng cách tùy chỉnh backend, có thể giảm thiểu việc tiếp xúc với dữ liệu nhạy cảm, điều chỉnh các biện pháp bảo mật cho từng client

3. Khi nào nên sử dụng Backend for Frontend Pattern?

Vậy khi nào chúng ta nên sử dụng BFF vào các dự án. Với kiến trúc như BFF sẽ đem lại hiệu quả rất lớn khi áp dụng:

• Yêu cầu đa dạng của client: Khi ứng dụng của bạn có nhiều loại frontend (ví dụ: web, mobile, app, ..) với dữ liệu hoặc nhu cầu tương tác riêng biệt. Lúc này mỗi client có thể có một backend để đáp ứng các yêu cầu riêng biệt của mình.

• API phức tạp: Nếu các dịch vụ backend của bạn cung cấp các tập dữ liệu lớn, phức tạp đòi hỏi transform hoặc filter nhiều, BFF sẽ giúp chuyển tải quá trình xử lý này sang một backend chuyên dụng, giúp giảm độ phức tạp của frontend.
• Phát triển frontend độc lập: Nếu các ứng dụng frontend của bạn phát triển ở các tốc độ khác nhau hoặc yêu cầu các tính năng và bản cập nhật riêng, mẫu BFF cho phép mỗi frontend có backend riêng có thể được sửa đổi độc lập mà không ảnh hưởng đến các khách hàng khác.
• Security và Authorization: Khi các máy khách khác nhau yêu cầu các mức độ truy cập dữ liệu hoặc security khác nhau, BFF có thể thực thi các quy tắc authentication, filter dữ liệu và cấp phép cụ thể cho từng client, đảm bảo kiểm soát truy cập phù hợp.

4. Khi nào không nên sử dụng Backend for Frontend Pattern?

Mô hình Backend cho Frontend (BFF) thường sẽ không hiệu quả nếu áp dụng vào các tình huống sau:

• Ứng dụng đơn giản: Nếu ứng dụng của bạn chỉ có một loại giao diện (ví dụ: chỉ có ứng dụng web) hoặc có ít sự khác biệt giữa các frontend, việc tạo nhiều BFF sẽ làm tăng thêm độ phức tạp không cần thiết.
• Chi phí thấp: Việc duy trì nhiều BFF đòi hỏi thêm cơ sở hạ tầng, monitoring và team phát triển. Nếu nhóm của bạn thiếu nguồn lực để quản lý nhiều dịch vụ backend, mô hình này có thể gây ra nhiều gánh nặng hơn là lợi ích.
• Backend phù hợp với mọi client: Nếu phần backend hiện tại đã phục vụ hiệu quả cho nhiều client mà không cần transform response phức tạp hay logic riêng biệt, thì việc thêm BFF có thể trở nên thừa thãi.
• Liên kết chặt chẽ: Nếu logic giữa frontend và backend được liên kết chặt chẽ và những thay đổi của một bên thường xuyên yêu cầu bên kia thay đổi, điều này dẫn tới việc duy trì BFF riêng biệt cho từng máy khách có thể làm phức tạp chu kỳ development và deployment.
• Microservice: Nếu hệ thống đã áp dụng kiến trúc microservice và các service đã được thiết kế đáp ứng nhu cầu thay đổi của client, thì mô hình BFF không cần thiết.

5. Backend for Frontend Pattern hoạt động như thế nào?

Cách mà BFF hoạt động như sau:

• Frontend (Web/Mobile/…): gửi request → đến BFF tương ứng (ví dụ: /api/mobile/user-profile)
• BFF: xử lý request theo cách tối ưu riêng cho frontend, gọi đến các service nội bộ (user service, order service, v.v), Ghép nhiều API thành một, format lại dữ liệu cho phù hợp với UI của client.
• BFF phản hồi dữ liệu: Dữ liệu đã được transform đúng yêu cầu frontend.

Hãy nhìn vào sequence diagram sau để rõ hơn về luồng hoạt động của BFF:

6. Các bước để triển khai Backend for Frontend Pattern

Cuối cùng khi đã hiểu tất cả về BFF, chúng ta sẽ áp dụng nó trong dự án như thế nào. Chúng ta sẽ implement BFF theo các bước sau:

 

• Xác định các Frontend: Phân tích nhu cầu của từng client (ví dụ: web, di động, app, IoT, ..) và xác định dữ liệu và yêu cầu tương tác của các client khác nhau như thế nào. Điều này sẽ giúp chúng ta quyết định xem có cần các backend riêng biệt cho từng frontend hay không.
• Thiết kế BFF cho từng Client: Tạo các endpoint API bff cho từng frontend. Điều chỉnh các API này để chỉ cung cấp dữ liệu và logic cần thiết theo yêu cầu của client cụ thể đó. Ví dụ: api/mobile/user-profile nhẹ hơn so với api/web/user-profile.
• Triển khai BFF: Xây dựng một BFF cho từng client (web, di động, v.v.). Mỗi BFF phải tổng hợp, xử lý hoặc chuyển đổi dữ liệu từ các dịch vụ backend, giúp response trở nên tối ưu cho từng client.
• Tích hợp Backend: BFF phải giao tiếp với các backend đơn khối hoặc microservice hiện có để truy xuất, chuyển đổi và kết hợp dữ liệu. Đảm bảo rằng các backend của bạn vẫn độc lập với client, trong khi BFF xử lý các nhu cầu cụ thể của frontend.
• Chuyển logic business từ frontend vào BFF: Di chuyển bất kỳ logic business phức tạp hoặc chuyển đổi dữ liệu nào từ frontend vào BFF. 
• Tối ưu performance: Triển khai cache, phân trang và tối ưu hóa response trong BFF để giảm độ trễ và cải thiện hiệu suất của client.
• Authorization: Thiết lập các chính sách khác nhau tùy vào BFF
• Monitoring BFF: Giám sát hiệu suất và tình trạng của từng BFF để đảm bảo BFF hoạt động hiệu quả. Bảo trì và mở rộng quy mô phải được quản lý riêng cho từng BFF
• Testing and deployment: Kiểm tra từng BFF riêng biệt để đảm bảo BFF hoạt động tốt với frontend tương ứng. Khi đã sẵn sàng, hãy deploy các BFF, giữ chúng tách biệt để những thay đổi đối với một frontend không ảnh hưởng đến các frontend khác.
• Loop and development: Khi frontend thay đổi, hãy cập nhật BFF cho phù hợp, thêm các tính năng mới hoặc tối ưu hóa cụ thể cho từng client.

Backend For Frontend là một mẫu thiết kế được tạo ra với sự quan tâm đến nhà phát triển và quan trọng hơn là user và trải nghiệm của họ. Đây là minh chứng cho việc áp dụng các mô hình mới để đáp ứng, tương tác và phục vụ khách hàng, đảm bảo tính nhất quán trong khi vẫn đáp ứng được các nhu cầu đa dạng và không ngừng phát triển của họ.

Trên đây là một số thông tin tôi muốn chia sẻ đến các bạn đọc giả về kiến trúc Backend for frontend mà tôi tổng hợp được. Hy vọng các bạn sẽ thích, hẹn gặp lại.

Mọi người có thể tham khảo thêm cha đẻ của BFF tại đây