BFF

Une couche qui adapte le backend aux besoins du frontend, en agrégeant et en transformant les données pour améliorer l'expérience du client.

Qu’est-ce qu’un BFF ?

BFF signifie Backend for Frontend. C’est une couche intermédiaire conçue pour servir un canal ou une interface spécifique, comme une SPA web, une application mobile ou un portail d’administration.

Son rôle n’est pas de remplacer les microservices, mais de traduire leur complexité en réponses plus utiles pour l’UI.

Quel problème résout-il ?

Imaginez un frontend qui a besoin de :

• données utilisateur
• données de commandes
• données de produits recommandés
• métriques ou état supplémentaire

Sans BFF, le client pourrait être contraint de :

• appeler plusieurs services
• comprendre des formats différents
• combiner des réponses
• gérer des erreurs distribuées
• se coupler à des détails internes

Le BFF réduit cette complexité.

Responsabilités principales

Agrégation de données

Combiner les informations de plusieurs services en une seule réponse.

Transformation en DTO d’UI

Fournir les données dans un format utile pour des écrans spécifiques.

Optimisation du payload

Réduire les appels inutiles et simplifier les réponses.

Mise en cache en lecture

Conserver les réponses fréquentes pour améliorer la latence et réduire la charge.

Orchestration simple

Coordonner les appels entre services lorsque le frontend a besoin d’une vue composée.

Ce qu’il ne devrait pas faire

Il ne devrait pas contenir la logique métier centrale

Il peut coordonner et transformer, mais ne doit pas devenir la couche où réside le domaine.

Il ne devrait pas remplacer les microservices

Les services restent responsables des règles métier.

Il ne devrait pas croître sans contrôle

Un BFF mal gouverné peut finir par devenir un « backend monolithique pour l’UI ».

Quand apporte-t-il le plus de valeur

Le BFF est particulièrement utile lorsque :

• le frontend a besoin de données provenant de plusieurs services
• il y a une optimisation spécifique par canal
• vous voulez éviter de multiples requêtes depuis le client
• vous avez besoin de DTO pensés pour l’UI
• vous avez plusieurs canaux aux besoins différents

BFF unique vs plusieurs BFF

Dans certains systèmes, un seul BFF suffit. Dans d’autres, il peut être judicieux de séparer :

• BFF web
• BFF mobile
• BFF admin

La décision dépend du degré de différence entre les besoins de chaque canal.

REST ou GraphQL

Un BFF peut être implémenté avec :

• REST
• GraphQL
• une combinaison des deux

GraphQL est souvent intéressant lorsqu’il y a une agrégation complexe et un besoin de contrôler précisément quels champs l’UI consomme. REST peut être suffisant et plus simple dans de nombreux contextes.

Exemple pratique

Prenons l’écran d’accueil d’un e-commerce.

L’UI a besoin de :

• profil de l’utilisateur
• commandes récentes
• produits recommandés

Le BFF peut :

1. Interroger ms-users
2. Interroger ms-orders
3. Interroger ms-products
4. Combiner les résultats
5. Renvoyer un DTO prêt à être affiché

Ainsi, le frontend effectue un seul appel et reçoit une réponse adaptée à son besoin.

Résumé

Le BFF existe pour adapter le backend au frontend. Sa valeur réside dans la simplification de l’UI, l’agrégation des réponses et la réduction du couplage, non dans l’absorption de la logique principale du domaine.