Architecture
Diagramme d'architecture Backend-for-Frontend avec des couches BFF séparées pour les clients web et mobile, chacune optimisant les réponses API pour sa plateforme spécifique tout en partageant des microservices backend communs. Ce modèle montre comment éviter les API universelles en adaptant l'agrégation des données et l'optimisation des charges utiles par type de client. Recommandé pour les équipes servant plusieurs plateformes frontend depuis un backend microservices partagé.
Code FlowZap complet
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"]
}
Pourquoi ce workflow ?
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.
Comment ça fonctionne
- 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.
Alternatives
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 | Architecture Backend-for-Frontend (BFF) pour microservices |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture de passerelle API pour microservices montrant le routage des requêtes, l'authentification JWT, la limitation de débit, la découverte de services et l'agrégation des réponses à travers des services backend distribués. Ce modèle représente le point d'entrée de tout le trafic client dans un écosystème de microservices, appliquant les politiques de sécurité avant que les requêtes n'atteignent les services internes. Idéal pour les ingénieurs plateforme concevant une infrastructure API évolutive avec des préoccupations transversales centralisées.
Architecture
Diagramme d'architecture base de données par service où chaque microservice possède son propre magasin de données dédié, avec synchronisation événementielle via Kafka pour la cohérence des données inter-services. Ce modèle démontre le principe fondamental d'isolation des données des microservices, montrant comment PostgreSQL et MongoDB coexistent dans une stratégie de persistance polyglotte. Critique pour les architectes imposant l'autonomie des services tout en maintenant la cohérence à terme.
Architecture
Diagramme d'architecture de chorégraphie événementielle où les microservices se coordonnent par événements sans orchestrateur central, avec les services Commande, Paiement, Inventaire et Expédition réagissant aux événements de domaine les uns des autres. Ce modèle représente le pattern de coordination décentralisée où chaque service ne connaît que ses propres responsabilités et publie des événements pour que d'autres les consomment. Idéal pour les équipes favorisant l'autonomie des services plutôt que le contrôle centralisé des workflows.
Architecture
Diagramme d'architecture saga par orchestration avec un orchestrateur central coordonnant des transactions distribuées multi-étapes à travers les services Commande, Inventaire et Paiement, avec une chaîne de compensation dédiée pour le rollback en cas d'échec. Ce modèle représente le pattern saga basé sur l'orchestration où un coordinateur unique gère le cycle de vie de la transaction et déclenche des actions compensatoires lorsqu'une étape échoue. Essentiel pour les architectes implémentant des transactions distribuées fiables sans commit en deux phases.
Architecture
Diagramme d'architecture de composition d'API avec un service compositeur qui distribue des requêtes parallèles vers plusieurs microservices, collecte les réponses avec gestion de timeout et fusionne les résultats en une réponse unifiée unique avec support de repli partiel. Ce modèle représente le pattern de composition d'API utilisé lorsqu'une requête client unique nécessite des données de plusieurs services, évitant les appels directs de service à service. Utile pour les équipes construisant des couches d'agrégation dans les architectures microservices.
Architecture
Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.