微服务 Backend-for-Frontend (BFF) 架构

Architecture

Backend-for-Frontend 架构图，为 Web 和移动客户端提供独立的 BFF 层，每层针对其特定平台优化 API 响应，同时共享通用后端微服务。该模板展示如何通过按客户端类型定制数据聚合和负载优化来避免一刀切的 API。推荐给从共享微服务后端服务多个前端平台的团队。

下载 .fz 文件

完整 FlowZap 代码

WebApp { # Web Application
n1: circle label:"Browser Request"
n2: rectangle label:"Web BFF"
n3: rectangle label:"Render HTML Response"
n4: circle label:"Display Page"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Services.n9.handle(top) [label="Fetch Data"]
n3.handle(right) -> n4.handle(left)
}
MobileApp { # Mobile Application
n5: circle label:"Mobile API Call"
n6: rectangle label:"Mobile BFF"
n7: rectangle label:"Optimized Payload"
n8: circle label:"Render Native UI"
n5.handle(right) -> n6.handle(left)
n6.handle(bottom) -> Services.n9.handle(top) [label="Fetch Data"]
n7.handle(right) -> n8.handle(left)
}
Services { # Shared Microservices
n9: rectangle label:"User Profile Service"
n10: rectangle label:"Content Service"
n11: rectangle label:"Notification Service"
n12: rectangle label:"Analytics Service"
n9.handle(right) -> n10.handle(left) [label="User Context"]
n10.handle(top) -> WebApp.n3.handle(bottom) [label="Full Payload"]
n10.handle(top) -> MobileApp.n7.handle(bottom) [label="Compact Payload"]
n11.handle(top) -> MobileApp.n7.handle(bottom) [label="Push Token"]
n12.handle(top) -> WebApp.n2.handle(bottom) [label="Track"]
n12.handle(top) -> MobileApp.n6.handle(bottom) [label="Track"]
}

为什么需要这个工作流？

A single API serving both web and mobile clients forces compromises: web clients receive unnecessary mobile-specific fields, and mobile clients download bloated payloads. The BFF pattern creates dedicated API layers for each client type, optimizing response payloads, aggregation logic, and caching strategies per platform.

工作原理

Step 1: The Web BFF aggregates data from shared microservices and renders full HTML payloads.
Step 2: The Mobile BFF returns compact JSON optimized for bandwidth-constrained mobile networks.
Step 3: Both BFFs call the same shared backend microservices for data.
Step 4: Each BFF handles platform-specific concerns like push notifications or SSR.
Step 5: Analytics tracking is integrated at the BFF level for platform-specific metrics.
Step 6: Shared microservices remain platform-agnostic and focused on business logic.

替代方案

A single API with field selection (GraphQL) can reduce the need for BFFs. API versioning per client type is simpler but harder to maintain. This template helps teams decide when a dedicated BFF layer is worth the operational cost.

Key Facts

Template Name	微服务 Backend-for-Frontend (BFF) 架构
Category	Architecture
Steps	6 workflow steps
Format	FlowZap Code (.fz file)