Qu'est-ce que le Backend for Frontend (BFF)

Un Backend for Frontend (BFF) est un service backend dédié, conçu pour une interface utilisateur spécifique. Au lieu que chaque client (web, iOS, Android, tiers) communique avec le même backend à usage général, chacun dispose de sa propre couche côté serveur qui agrège et remodèle les données de vos microservices pour former exactement la charge utile dont cette interface a besoin.

Sam Newman a nommé et popularisé ce modèle en 2015, s'inspirant des travaux réalisés chez SoundCloud. Plus d'une décennie plus tard, le modèle BFF reste un outil standard pour les équipes gérant des microservices derrière plusieurs applications clientes, et Microsoft le documente comme un modèle d'architecture cloud essentiel.

Le problème qu'un BFF résout

Imaginez un système qui a débuté avec une seule application web et un seul backend. Le backend exposait des endpoints REST, l'application web les consommait, et la vie était simple. Ensuite, l'entreprise a lancé une application mobile. Puis une intégration partenaire. Puis un widget de montre connectée. Soudain, quatre clients très différents tirent tous du même backend, et ce backend essaie de satisfaire tout le monde en même temps.

Cela crée deux problèmes récurrents.

Sur-extraction (over-fetching) et sous-extraction (under-fetching). Un endpoint à usage général renvoie une forme de données fixe. Un tableau de bord de bureau pourrait vouloir l'enregistrement complet du client avec l'historique des commandes, les recommandations et les paramètres de compte en une seule réponse. Une application mobile sur une connexion cellulaire instable ne veut que trois champs et rien de plus. Lorsque les deux accèdent au même endpoint, l'un d'eux obtient une quantité de données incorrecte. Le client mobile télécharge soit une charge utile volumineuse qu'il doit écarter (sur-extraction), soit doit effectuer plusieurs allers-retour supplémentaires pour assembler ce dont il a besoin (sous-extraction).

Clients bavards. Lorsqu'un backend n'est pas adapté à un écran, le client compense en effectuant de nombreux appels. Un écran d'accueil mobile qui a besoin des données de profil, d'un nombre de notifications et d'un flux pourrait déclencher trois ou quatre requêtes distinctes vers trois ou quatre microservices, puis assembler les résultats sur l'appareil. Chaque aller-retour supplémentaire coûte en latence et en batterie, et la logique d'orchestration s'immisce dans le client où elle est difficile à tester et à versionner.

La tension fondamentale est autant organisationnelle que technique. Un backend partagé doit faire face aux exigences concurrentes de chaque équipe frontend. La modification d'une équipe doit être validée par rapport aux besoins de toutes les autres équipes avant d'être déployée, ce qui transforme le backend en goulot d'étranglement et en source de frictions inter-équipes.

Comment fonctionne le modèle BFF

Le modèle BFF introduit une fine couche côté serveur qui se situe entre une interface utilisateur et vos services en aval. Chaque interface dispose de son propre backend.

[ Web app ]    --->  [ Web BFF ]    ---\
[ iOS app ]    --->  [ iOS BFF ]    -----> [ Microservices ]
[ Android app] --->  [ Android BFF ] ---/

Chaque BFF remplit trois fonctions pour son client :

1. Agrégation. Il appelle les microservices en aval dont l'écran a besoin et combine leurs réponses, de sorte que le client effectue une seule requête au lieu de cinq. Il s'agit d'une agrégation d'API appliquée à une expérience utilisateur unique. Si vous souhaitez une version générale de cette idée, consultez notre explication sur le modèle d'agrégateur d'API.
2. Remodelage. Il élague les champs, renomme les éléments en termes conviviaux pour le client, aplatit les structures imbriquées et formate les valeurs comme l'interface l'attend. Le BFF mobile renvoie des charges utiles légères ; le BFF de bureau renvoie des charges utiles riches.
3. Traduction. Il gère les préoccupations spécifiques au client telles que la stratégie de pagination, la mise en cache des réponses adaptée à ce client et les choix de protocole, sans imposer ces décisions aux services partagés sous-jacents.

Les microservices en aval restent polyvalents et agnostiques à l'interface. Ils exposent des capacités propres et réutilisables. Le BFF est l'endroit où réside la mise en forme spécifique au client, ce qui maintient cette logique hors des microservices et de l'application cliente. Si vous débutez avec la couche de service sous-jacente, notre aperçu des microservices par rapport aux API et le passage d'un monolithe aux microservices définissent le contexte.

Un BFF par expérience client

La ligne directrice principale de Newman est courte : une expérience, un BFF. Si vos applications iOS et Android offrent des expériences significativement différentes, attribuez à chacune son propre BFF. Si une application web et une application mobile divergent, la même règle s'applique.

Le but de la règle est de maintenir chaque BFF ciblé. Dès qu'un seul BFF essaie de servir deux clients ayant des besoins différents, il commence à accumuler de la logique conditionnelle (« si mobile, renvoie ceci ; si web, renvoie cela »), et vous revenez à un backend à usage général avec tous les mêmes problèmes de coordination. Un BFF ciblé reste petit, ce qui est la propriété qui rend le modèle entier rentable.

Il existe une exception raisonnable que Newman lui-même tire de SoundCloud : lorsqu'une équipe possède deux clients similaires, tels que des applications iOS et Android qui partagent presque la même expérience, il peut être raisonnable de partager un seul BFF mobile entre elles. Le facteur décisif est la propriété et la similarité, et non les noms de plateforme. La règle est une valeur par défaut, pas une loi.

La propriété appartient à l'équipe frontend

Un BFF n'est pas une couche que l'équipe de plateforme construit et transmet. L'équipe frontend qui possède le client possède son BFF. C'est la seconde moitié de ce qui fait fonctionner le modèle.

Lorsque l'équipe frontend possède le BFF, elle contrôle sa cadence de publication, choisit son langage et son environnement d'exécution, priorise son backlog et déploie les modifications du client et de son service de support ensemble. Une modification de l'interface utilisateur qui nécessite un nouvel endpoint agrégé ne demande pas de déposer un ticket auprès d'une équipe backend distincte et d'attendre qu'elle traite la demande. L'équipe qui ressent la douleur possède la solution.

Cette autonomie est le véritable avantage. Le BFF déplace la limite de sorte que les décisions spécifiques au client sont prises par les personnes responsables du client, ce qui est exactement là où la pensée de la connectivité guidée par API place le niveau « expérience ».

BFF vs Passerelle API

C'est la comparaison sur laquelle la plupart des équipes butent, car un BFF et une passerelle API se ressemblent sur un diagramme. Tous deux se situent entre les clients et les services. Tous deux peuvent router et agréger. Mais ils répondent à des questions différentes.

Une passerelle API est un point d'entrée à usage général qui gère les préoccupations transversales pour tout le trafic : authentification, limitation de débit, routage, terminaison TLS et journalisation des requêtes. Elle est la propriété d'une équipe plateforme ou infrastructure et est délibérément agnostique au client. Une passerelle sert tout le monde de la même manière.

Un BFF est l'opposé. Il est spécifique au client par conception, détenu par une équipe frontend, et son but est d'être différent pour chaque interface. C'est l'endroit où réside la mise en forme de la charge utile d'un client, et non un point d'étranglement partagé.

Les deux ne sont pas des rivaux. Dans une architecture de production courante, une passerelle API se trouve en amont, gérant l'authentification, la limitation de débit et la surveillance de tout le trafic, puis achemine chaque client vers son BFF dédié derrière la passerelle. L'architecture de référence de Microsoft montre exactement cela : une passerelle gérant les préoccupations transversales, avec un BFF serverless par client derrière elle. Utilisez la passerelle pour ce qui est commun à tous les clients, et un BFF pour ce qui est différent. (Nous couvrons la version approfondie de ce contraste dans un article séparé ; il suffit ici de savoir qu'ils se situent à des couches différentes et répondent à des besoins différents.)

Pour le paysage des passerelles, ces comparaisons publiées sont utiles : gestion d'API vs passerelle API, passerelle API vs équilibreur de charge, et maillage de services vs passerelle API.

Quand utiliser un BFF

Le modèle s'avère utile lorsque ces conditions sont remplies :

• Vous avez plusieurs clients réellement différents. Web plus mobile plus une intégration partenaire, chacun avec des besoins en données distincts. Plus les expériences divergent, plus un BFF est utile.
• Un backend partagé est devenu un goulot d'étranglement. Si chaque modification frontend force une négociation inter-équipes, la division de la mise en forme spécifique au client en BFFs par équipe élimine les frais de coordination.
• Vous voulez des charges utiles optimisées pour le client. Le mobile a besoin de réponses légères et d'une mise en cache agressive ; le bureau veut des données agrégées riches. Un BFF vous permet d'optimiser chaque cas sans compromis.
• Un langage convient mieux à un frontend. Une équipe peut construire son BFF dans l'environnement d'exécution qui convient à son client, indépendamment de ce que les autres BFFs utilisent.

Quand ne pas utiliser un BFF

Le modèle n'est pas gratuit, et il existe des cas clairs où il ajoute des coûts sans retour sur investissement :

• Vous n'avez qu'un seul client. Avec une seule interface, un BFF n'est qu'un saut supplémentaire. Construisez un backend normal.
• Vos clients font les mêmes requêtes. Si le web et le mobile veulent des données presque identiques dans la même forme, des BFFs séparés dupliquent les efforts sans avantage. Consolidez plutôt.
• GraphQL résout déjà votre problème de mise en forme. Avec GraphQL, chaque client interroge exactement les champs dont il a besoin à partir d'un seul endpoint, ce qui couvre la sur-extraction et la sous-extraction sans backend par client. Si vous disposez d'une couche GraphQL avec des résolveurs spécifiques au frontend, un niveau BFF séparé n'ajoute souvent aucune valeur. Voir ce qu'est GraphQL pour juger s'il convient avant d'ajouter un niveau BFF.
• Une passerelle et des microservices suffisent. Pour les systèmes plus simples, une passerelle API devant des microservices bien conçus peut fournir des résultats acceptables sans une couche dédiée par client.

Les inconvénients honnêtes

Même lorsqu'un BFF est la bonne solution, vous encourez des coûts réels. Aborder la situation en toute connaissance de cause fait partie de la bonne utilisation du modèle.

• Duplication de code. C'est le compromis principal, et la documentation de Microsoft le souligne directement. Lorsque trois BFFs doivent tous appeler la même vérification d'authentification ou formater la même date de la même manière, cette logique a tendance à être écrite trois fois. Vous échangez la duplication contre l'adaptation. La solution est la discipline : conservez la logique véritablement partagée dans les bibliothèques importées par les BFFs, et réservez le BFF lui-même à la mise en forme spécifique au client. Remontez les véritables préoccupations transversales (authentification, limitation de débit, surveillance) vers la passerelle plutôt que de les réimplémenter par BFF.
• Plus de services à opérer. Chaque BFF est une autre unité déployable avec son propre cycle de vie, pipeline, rotation d'astreinte et surface de sécurité. Plus de services signifie plus de frais généraux opérationnels.
• Un saut réseau supplémentaire. Les clients ne communiquent plus directement avec les services. Le BFF ajoute un saut, ce qui peut entraîner une latence. C'est généralement un compromis judicieux car le BFF supprime plusieurs allers-retours client, mais c'est un coût à mesurer, pas à supposer.
• Risque que le BFF devienne surchargé. Si un BFF commence à servir plusieurs clients ou à absorber une logique métier qui appartient aux microservices, il tend à redevenir le backend à usage général auquel vous essayiez d'échapper. Gardez-le léger.

Maintenir la synchronisation des contrats BFF avec Apidog

La difficulté pratique de l'exécution des BFFs réside dans les contrats. Chaque BFF expose sa propre API côté client, et dépend également des contrats des microservices qui lui sont sous-jacents. Cela représente de nombreuses interfaces en mouvement entre des équipes possédant différentes couches, et les dérives entre elles sont la source des bugs et des clients défectueux.

C'est là que Apidog s'intègre au workflow. Apidog est une plateforme de conception, de test, de simulation et de documentation d'API, de sorte que le contrat API de chaque BFF dispose d'un emplacement unique sur lequel les équipes frontend et backend peuvent toutes deux travailler :

• Concevez le contrat en premier. Définissez chaque endpoint BFF et son schéma de requête et de réponse dans le concepteur visuel d'Apidog avec OpenAPI en dessous, afin que la forme côté client soit convenue avant l'écriture du code. C'est l'approche contract-first appliquée à la couche BFF, et elle rend le contrat API explicite.
• Simulez-le avant qu'il n'existe. L'équipe frontend peut commencer à développer contre une simulation intelligente Apidog du BFF le jour où le contrat est accepté, sans attendre que le BFF ou ses services en aval soient prêts.
• Testez le contrat. Les tests et assertions automatisés d'Apidog vérifient que chaque BFF renvoie la charge utile agrégée et remodelée attendue par son client, et ils s'intègrent dans la CI afin qu'une modification en aval qui rompt une réponse BFF soit détectée tôt.
• Documentez pour les deux parties. Apidog génère automatiquement des documents interactifs à partir du contrat, de sorte que l'équipe frontend lisant l'API du BFF et l'équipe backend propriétaire des services sous-jacents partagent une source unique de vérité.

Pour être clair sur la portée : Apidog ne construit, n'héberge ni n'exécute votre BFF, et ce n'est pas une passerelle API. C'est là que vous concevez, simulez, testez et documentez le contrat API sur lequel chaque BFF repose, ce qui maintient les équipes frontend et backend synchronisées à mesure que les BFFs évoluent. Traiter chaque BFF comme un produit avec un contrat stable et bien documenté est ce qui rend le modèle durable.

FAQ

Un BFF est-il un microservice ? Un BFF est un service côté serveur, et dans une architecture de microservices, il fonctionne généralement comme tel. Mais son rôle est différent de celui d'un microservice typique. Un microservice possède une capacité métier et reste agnostique au client ; un BFF possède l'expérience d'un client et existe pour agréger et remodeler ces microservices pour ce client. C'est un service de couche d'expérience, pas un service de capacité métier.

Combien de BFFs devrais-je avoir ? La valeur par défaut est un par expérience client distincte : un pour le web, un pour iOS, un pour Android, et ainsi de suite. Ne combinez-en deux que lorsqu'une seule équipe possède des clients ayant des besoins presque identiques. Séparez-les davantage lorsqu'un BFF commence à accumuler de la logique conditionnelle spécifique au client.

GraphQL remplace-t-il le modèle BFF ? Il le peut, pour la partie mise en forme de la charge utile. GraphQL permet à chaque client de demander exactement les champs dont il a besoin à partir d'un seul endpoint, ce qui couvre la sur-extraction et la sous-extraction sans backend par client. Si vous utilisez GraphQL avec des résolveurs spécifiques au frontend, une couche BFF séparée n'ajoute souvent que peu de valeur. Les BFFs sont toujours utiles lorsque vous avez besoin d'orchestration par client, de traduction de protocole ou de choix d'environnement d'exécution qu'un serveur GraphQL partagé ne peut pas facilement fournir.

Puis-je utiliser un BFF et une passerelle API ensemble ? Oui, et c'est courant. La passerelle API gère les préoccupations partagées par tous les clients, telles que l'authentification, la limitation de débit et la surveillance, et achemine le trafic vers le bon BFF. Chaque BFF gère ce qui est spécifique à son client. Ils se situent à des couches différentes et remplissent des fonctions différentes.

Qui devrait posséder le BFF ? L'équipe frontend qui possède le client. Cette propriété est essentielle au modèle. Elle permet à l'équipe de déployer les modifications de l'interface utilisateur et les endpoints de support ensemble, de choisir son propre environnement d'exécution et d'avancer sans attendre dans la file d'attente d'une équipe backend distincte.

Un BFF ajoute-t-il de la latence ? Il ajoute un saut réseau, ce qui a un coût. En pratique, il réduit généralement la latence totale du client, car il remplace plusieurs allers-retours client-service par une seule requête client-BFF et permet au BFF d'appeler les services en parallèle à proximité de ceux-ci. Mesurez-le pour votre charge de travail plutôt que de faire des suppositions.