Backend for Frontend (BFF)

Comment créer des backends spécialisés par type de client afin d'optimiser l'expérience de chaque plateforme sans coupler les services internes.

Quel problème résout-il

Dans une architecture de microservices dotée d’un API Gateway unique, tous les clients (web, mobile, IoT, smart TV) consomment la même API. Or, chaque client a des besoins très différents :

• Mobile : Nécessite des réponses compactes (bande passante limitée), des données agrégées en peu d’appels
• Web SPA : Peut gérer davantage de données, nécessite de la pagination et des filtres avancés
• IoT : N’a besoin que d’un sous-ensemble minimal de données avec des protocoles légers

Problème avec un seul API Gateway :
  Mobile App ──► API Gateway ──► Microservicios
  Web App    ──► (misma API)
  IoT Device ──► (misma API)
  
  La API devuelve TODOS los campos para TODOS los clientes
  Mobile recibe datos que no necesita → desperdicio de ancho de banda
  Web no puede pedir datos extra sin afectar a mobile
  Cada cambio en la API afecta a todos los clientes

Le résultat est une API « one-size-fits-all » qui ne satisfait pleinement aucun client, ou bien une API truffée de paramètres conditionnels (?platform=mobile&fields=name,price) qui devient difficile à maintenir.

Comment ça fonctionne

Le pattern BFF propose de créer un backend dédié à chaque type de client. Chaque BFF est un service léger qui joue le rôle d’intermédiaire entre son client spécifique et les microservices internes.

Con BFF:
  Mobile App ──► BFF Mobile  ──┐
  Web App    ──► BFF Web     ──┤──► Microservicios
  IoT Device ──► BFF IoT     ──┘
  
  Cada BFF adapta las respuestas a su cliente
  Cada equipo de frontend controla su BFF
  Los microservicios no cambian

Responsabilités du BFF

Exemple : endpoint de produit

Microservicio Product Service devuelve:
{
  "id": "P001",
  "name": "Laptop Pro",
  "description": "Laptop de alto rendimiento...",
  "specs": { "cpu": "i9", "ram": "32GB", "storage": "1TB" },
  "images": ["url1.jpg", "url2.jpg", "url3.jpg", "url4.jpg"],
  "reviews": [...50 reviews...],
  "relatedProducts": [...10 productos...],
  "inventory": { "warehouse1": 50, "warehouse2": 30 },
  "pricing": { "base": 1500, "discount": 10, "tax": 15 }
}

BFF Mobile devuelve:
{
  "id": "P001",
  "name": "Laptop Pro",
  "image": "url1_thumb.jpg",
  "price": "$1,350",
  "rating": 4.5
}

BFF Web devuelve:
{
  "id": "P001",
  "name": "Laptop Pro",
  "description": "Laptop de alto rendimiento...",
  "specs": { "cpu": "i9", "ram": "32GB", "storage": "1TB" },
  "images": ["url1.jpg", "url2.jpg", "url3.jpg", "url4.jpg"],
  "reviewSummary": { "average": 4.5, "count": 50 },
  "price": { "original": 1500, "final": 1350, "discount": "10%" },
  "relatedProducts": [...3 productos...]
}

Propriété du BFF

Un principe clé du pattern est que l’équipe frontend est propriétaire de son BFF. Cela permet :

• L’équipe mobile décide des données dont elle a besoin et de la manière de les structurer
• Les changements dans l’UI ne nécessitent pas de coordination avec les autres équipes
• Chaque BFF évolue au rythme de son client

Avantages

• Optimisation par client : Chaque plateforme reçoit exactement les données dont elle a besoin
• Autonomie des équipes : L’équipe frontend contrôle son backend sans dépendre des autres
• Évolution indépendante : Les changements dans l’API mobile n’affectent ni le web ni l’IoT
• Performance : Moins de données transférées, moins d’appels depuis le client
• Simplicité du client : Le frontend consomme une API conçue spécifiquement pour lui
• Sécurité granulaire : Chaque BFF peut mettre en œuvre des politiques de sécurité spécifiques

Compromis / Inconvénients

• Duplication de code : Une logique similaire peut se répéter entre les BFF (atténuable avec des librairies partagées)
• Davantage de services à maintenir : Chaque BFF est un service supplémentaire qui nécessite déploiement et supervision
• Cohérence : Différents BFF peuvent renvoyer des données incohérentes s’ils ne sont pas coordonnés
• Complexité organisationnelle : Nécessite des équipes ayant des compétences full-stack (frontend + son BFF)
• Latence : Un saut supplémentaire entre le client et les microservices
• Risque de BFF monolithique : Si le BFF grossit trop, il se transforme en mini-monolithe

Quand l’utiliser

• Plusieurs types de clients avec des besoins de données très différents
• Des équipes frontend qui ont besoin d’autonomie pour faire évoluer leur API
• Des applications mobiles où la bande passante et le nombre d’appels sont critiques
• Lorsqu’un API Gateway unique devient trop complexe à cause de la logique conditionnelle par client
• Des organisations avec des équipes dédiées par plateforme (équipe mobile, équipe web)

Quand l’éviter

• Un seul type de client (uniquement web, ou uniquement mobile)
• Des clients aux besoins de données très similaires
• Des petites équipes où maintenir plusieurs BFF ne se justifie pas
• Lorsqu’un API Gateway avec des transformations simples suffit
• Des prototypes ou des MVP où la vitesse de développement est prioritaire

Technologies et implémentations courantes

Relation avec d’autres patterns

• API Gateway : Le BFF est une spécialisation de l’API Gateway par type de client
• Microservices : Les BFF consomment les microservices internes et les adaptent
• Anti-Corruption Layer : Le BFF peut jouer le rôle d’ACL entre le frontend et les services legacy
• Circuit Breaker : Chaque BFF doit implémenter un circuit breaking vers les services qu’il consomme

Prochaines étapes

Le BFF vous donne un contrôle granulaire sur l’expérience de chaque client. Pour comprendre comment décomposer les services que le BFF consomme, explorez le pattern Microservices. Pour protéger la communication entre le BFF et les services externes, consultez l’Anti-Corruption Layer.