Ton front a besoin d’un meilleur ami ? Parlons BFF.

Introduction

Un des patterns d'architecture que l'on voit de plus en plus souvent dans les grandes entreprises, notamment celles qui adoptent les microservices, est le Back-End For Front-End (BFF). La naissance d'une telle approche est due à plusieurs évolutions dans le développement Web :

• L'abandon progressif du monolithe tout-en-un front/back.
• L'utilisation de services tiers type SaaS.
• L'expérience utilisateur adaptée à diverses plateformes (Web, mobile, tablette…).

Qu'est-ce qu'un BFF ?

BFF est le diminutif de "Back-end-For-Front-end". C'est généralement un serveur web qui interroge une panoplie de services. Le but : fournir aux interfaces utilisateurs des données adaptées à leur UX.

Les microservices, de leur côté, tendent à se spécialiser sur un domaine métier en particulier (par exemple la facturation). Le BFF sert d'articulation entre ces derniers et construit une logique métier ou d'usage.

Voici un petit exemple illustratif :

• Un service fournit les niveaux de stock
• Un autre fournit la liste des articles
• Le BFF agrège ces deux services et expose à l'UI une vue "articles + stock"

Ainsi, dans des entreprises d'une certaine envergure et avec des besoins métier divers, la question qui revient : "Un BFF est-il approprié à mon usage ?"

La réponse, comme toujours, est : "Ça dépend !"

Comment savoir si j'en ai besoin ?

La démarche la plus simple consiste à procéder par élimination. Certains critères sont plus déterminants que d'autres :

1. J'ai plusieurs fronts avec des logiques communes ?

Le BFF est utile si :

• Plusieurs applications partagent la même logique métier
• Vous voulez mutualiser le code d'orchestration
• Vous souhaitez éviter la duplication de logique dans chaque front

Le BFF n'est pas utile si :

• Une seule application front
• Pas de réutilisation prévue

2. Mon UX est-elle spécifique au device ?

Le BFF est utile si :

• Vous avez des interfaces très différentes (Web, mobile, borne, IoT…)
• Chaque device a des besoins de données spécifiques
• L'expérience utilisateur varie fortement selon la plateforme

Le BFF n'est pas utile si :

• Une seule interface (par ex. Web uniquement)
• Les besoins de données sont identiques sur tous les devices

3. J'utilise beaucoup de providers ?

Le BFF est utile si :

• Vous interrogez plusieurs services tiers (SaaS, APIs externes…)
• Vous devez orchestrer et agréger des données de sources multiples
• La logique d'orchestration devient complexe côté front

Le BFF n'est pas utile si :

• Vous avez 1 à 2 services simples à interroger
• Pas d'orchestration complexe nécessaire
• Le front peut facilement gérer les appels directs

4. Comment je gère la sécurité de mon appli front ?

Le BFF est utile si :

• Gestion de sessions côté serveur nécessaire
• Authentification complexe (OAuth, SSO…)
• Besoin de masquer des credentials ou clés API au front
• Règles d'autorisation spécifiques ou granulaires

Le BFF n'est pas utile si :

• Authentification simple côté client
• Pas de secrets à protéger
• Les APIs backend gèrent déjà toute la sécurité

Étudions un cas concret

Prenons un cas concret : une application qui permet de gérer la relation client après-vente. Les utilisateurs peuvent consulter le détail d'un achat, une commande, les infos client, mais aussi la disponibilité des stocks, et effectuer des actions (annulation, retours...). Cette application serait utilisée par les employés d'un centre de relation client.

Défrichage initial

Énoncé comme cela, on ne voit pas trop l'intérêt d'un BFF. Pour y voir plus clair, on peut essayer d'effectuer un premier défrichage :

• Qui sont mes fournisseurs de données et d'interactions ?
• Sur quelle(s) plateforme(s) l'application sera disponible ?
• La logique business est-elle commune ou réutilisable ?
• L'outil est-il accessible aux clients finaux ?

Éléments d'analyse

Après des échanges avec le métier, on obtient davantage d'éléments :

• Les données sont disponibles depuis différents services internes.
• L'ensemble des interactions est couvert par des services internes.
• L'application sera aussi disponible pour les employés en magasin sur des bornes multiservices (Android).
• Les clients finaux n'ont pas accès à l'application (accès type intranet uniquement).

L'exemple est simplifié, mais il illustre bien la démarche de réflexion. Pour répondre à cette fameuse question, reprenons nos 4 critères :

Même si certains éléments peuvent être gérés côté front, cela engendre des inconvénients à long terme : duplication de logique, maintenance accrue, et complexité du front.

Un BFF permet de centraliser cette logique métier et de faire en sorte que le front se concentre uniquement sur l'interface (UI/UX).

L'aspect sécurité est tout aussi important : comment gardez-vous à l'abri sur une appli client vos clés d'API, vos jetons (bearers) ou les informations de session ?

Verdict : Oui, il nous faut un BFF !

• Centraliser la logique d'orchestration entre services
• Gérer l'authentification et les sessions de manière sécurisée
• Mutualiser le code entre les interfaces
• Adapter les données selon le contexte (borne vs web)

Et maintenant ?

Maintenant que la décision est prise, une nouvelle question se pose : comment l'implémenter ?

• Frameworks full-stack (Next, Nuxt, SvelteKit…)
• REST API (Express, Fastify...)
• GraphQL (Apollo, Yoga...)
• gRPC, tRPC…

Mais ça, ce sera pour le prochain article ! 😉

Conclusion

Décider si l'on a besoin d'un BFF n'est pas une question de mode technique, mais de contexte métier.

Voici les 4 questions à se poser pour orienter sa décision :

• Ai-je des UX spécifiques aux devices ?
• Ai-je un nombre important de providers à orchestrer ?
• Ma logique métier est-elle commune et réutilisable sur d'autres devices ?
• Dois-je gérer la sécurité (authentification, clés d'API, sessions utilisateurs...) ?

Si la majorité des réponses est "oui", il y a de fortes chances que vous ayez besoin d'un Back-end-For-Front-end.

Une question bien posée est déjà la moitié de sa réponse. Faire les bons choix, c'est avant tout se poser les bonnes questions.