Ce billet explore le pattern Backend-for-Frontend (BFF), une solution architecturale pour les applications modernes où plusieurs frontends (web, mobile, TV) consomment les mêmes services backend. Le BFF agit comme une couche de traduction dédiée à chaque client, agrégeant les appels API, transformant les données et gérant la logique spécifique (cache, authentification, etc.), le tout possédé et maintenu par l’équipe frontend.
Les signes qu’un BFF pourrait être utile incluent des problèmes de performance (appels multiples, sur/sous-récupération de données), une lenteur de développement (dépendances entre équipes, duplication de logique) ou des frictions organisationnelles (API mal adaptées aux besoins UX). Le BFF permet d’aligner les priorités des équipes, d’améliorer les performances (notamment sur mobile) et d’accélérer la livraison de fonctionnalités.
Cependant, le BFF n’est pas une solution universelle : il ajoute de la complexité opérationnelle et peut être excessif pour des applications simples ou des petites équipes. Des alternatives existent (GraphQL, API Gateway, refonte backend). L’article souligne l’importance d’un pilote pour évaluer son impact avant une adoption large, et rappelle que le succès dépend d’une appropriation par les équipes frontend et d’une approche itérative.
Le Backend For Frontend (BFF) est un pattern architectural qui agit comme une couche intermédiaire entre les applications frontend (web, mobile, etc.) et les API ou microservices. Son objectif est de simplifier la récupération et la transformation des données en centralisant la logique d’agrégation et d’adaptation des données côté serveur, plutôt que de la laisser aux clients. Cela évite de surcharger les applications frontend avec des tâches complexes et permet d’offrir une réponse sur mesure, optimisée pour chaque type de client (mobile, web, etc.). Contrairement à une API Gateway, le BFF est dédié à un type spécifique de client, ce qui permet de mieux répondre à ses besoins en termes de format de données, gestion d’erreurs ou authentification. Ce pattern est particulièrement utile dans un contexte MACH (Micro Services, API-first, Cloud Native, Headless) ou lorsque les besoins des utilisateurs varient selon le type d’application, mais il ajoute une couche supplémentaire à maintenir et nécessite des compétences fullstack. Son adoption se justifie surtout si l’expérience utilisateur doit être différente selon les plateformes.
L'auteur introduit la notion de BFF - Backend for Frontend - qui permet de combiner / orchestrer les requêtes du front : au lieu de multiplier les requêtes (CRM, commandes, notifications, etc.), on crée une API qui renvoie ces informations avec un seul appel. L'auteur montre ensuite comment GraphQL permet une grande flexibilité et évite "l'overfetching"