BFF vs API Gateway : Différences et cas d'utilisation

« BFF vs API Gateway » est l'une des confrontations les plus confuses dans l'architecture de microservices. Les deux modèles se ressemblent sur un diagramme. Tous deux se placent devant vos services. Tous deux reçoivent une requête client et la transmettent aux backends. Les équipes supposent donc qu'il s'agit de choix concurrents, en choisissent un, et finissent par y entasser les mauvaises responsabilités.

Ce ne sont pas des concurrents. Un Backend for Frontend (BFF) et une passerelle API (API gateway) résolvent des problèmes différents, sont gérés par des équipes différentes, et fonctionnent très souvent ensemble dans le même système. Le BFF se situe derrière ou à côté de la passerelle, et non à sa place.

Ce guide établit clairement la distinction. Vous apprendrez ce qu'est réellement chaque modèle, où ils se chevauchent, quand utiliser l'un ou les deux, et les erreurs qui résultent de leur confusion. Tout au long de ce guide, le contrat API est la constante : qu'une requête transite par une passerelle, un BFF, ou les deux, chaque couche expose une API que vous devez toujours concevoir, tester, simuler et documenter.

Qu'est-ce qu'une passerelle API (API Gateway) ?

Une passerelle API est un point d'entrée centralisé qui se situe entre les clients et vos services backend. Chaque requête transite par la passerelle, qui applique un ensemble cohérent de préoccupations transversales avant de router l'appel.

Ces préoccupations sont les mêmes pour chaque client et chaque service :

• Routage : faire correspondre un chemin entrant au service en amont approprié.
• Authentification et autorisation : valider les jetons, rejeter les appelants non autorisés.
• Limitation de débit (Rate limiting) et régulation (throttling) : protéger les backends contre la surcharge et les abus.
• Observabilité : enregistrer les requêtes, émettre des métriques, tracer les appels entre les services.
• Terminaison TLS, mise en cache et transformation des requêtes : gérer l'infrastructure une seule fois, à un seul endroit.

La caractéristique déterminante de la passerelle est qu'elle est polyvalente et gérée de manière centralisée. Une équipe de plateforme ou d'infrastructure la gère, et elle dessert tous les clients de manière égale. Peu importe si l'appelant est une application mobile, une SPA web ou une intégration partenaire ; elle applique les mêmes politiques à tous.

Cela fait de la passerelle l'endroit naturel pour les règles à l'échelle de l'organisation. Si vous souhaitez que chaque requête soit authentifiée de la même manière, ou que chaque API soit limitée en débit de manière cohérente, la passerelle l'applique sans que chaque service ne réimplémente la logique. Pour comprendre comment cela diffère des outils de plateforme plus larges, consultez Gestion des API vs passerelle API.

Qu'est-ce qu'un Backend for Frontend (BFF) ?

Un Backend for Frontend (BFF), introduit par Sam Newman, inverse l'orientation. Au lieu d'un backend polyvalent servant tous les clients, vous construisez un backend par expérience utilisateur. L'application web reçoit un BFF web. L'application mobile reçoit un BFF mobile. Chaque BFF est adapté précisément à un seul frontend. Ce modèle est né du travail sur les microservices, où un backend partagé unique servant de nombreux clients devient le même type de goulot d'étranglement qu'un monolithe.

La règle empirique de Newman est « une expérience, un BFF ». Les frontends significativement différents obtiennent leur propre BFF ; les similaires (une application iOS et une application Android maintenues par la même équipe) peuvent en partager un.

La caractéristique déterminante ici est la propriété et la forme. Un BFF est « étroitement lié à une expérience utilisateur spécifique et sera généralement maintenu par la même équipe que l'interface utilisateur », selon les mots de Newman. L'équipe frontend possède son BFF. Elle fait évoluer le client et son backend ensemble, sans attendre qu'une équipe backend distincte approuve chaque changement.

Que fait réellement un BFF ? Il adapte les données pour un client :

• Agrégation : un écran mobile a besoin de données provenant de cinq microservices. Le BFF mobile appelle les cinq et renvoie une réponse combinée, de sorte que le téléphone effectue un seul aller-retour au lieu de cinq.
• Élagage et remodelage : le client mobile n'a besoin que de trois champs sur quarante. Le BFF supprime le reste pour économiser de la bande passante.
• Formatage spécifique au client : l'application de bureau récupère plusieurs pages à la fois pour une vue enrichie ; l'application mobile récupère une seule page pour rester légère. Chaque BFF sert le modèle de son client.

Le BFF est une sorte d'agrégateur API avec une personnalité : il compose les appels en aval, mais toujours au service d'un frontend spécifique plutôt que comme une couche neutre et partagée.

Où le BFF et la passerelle API se chevauchent

La confusion est compréhensible car les deux modèles partagent des comportements de surface. Tous deux interceptent les requêtes client. Tous deux peuvent router vers des backends. Tous deux peuvent appeler plusieurs services et combiner les résultats. Un diagramme de l'un ou de l'autre ressemble à une boîte entre les clients et les services.

Le chevauchement est réel mais superficiel. La différence réside dans l'intention et la propriété :

• Une passerelle API agrège et route génériquement, pour tous les clients, afin de centraliser la politique.
• Un BFF agrège et route spécifiquement, pour un seul frontend, afin d'optimiser l'expérience de ce client.

Les propres directives de Microsoft sont franches quant à la répartition des tâches. Les fonctionnalités transversales comme la surveillance, l'autorisation et la limitation de débit devraient être abstraites du BFF et gérées séparément par des modèles de type passerelle. Le BFF ne devrait contenir que la logique spécifique au client. Si vous placez l'authentification et la régulation dans un BFF, vous venez de reconstruire la moitié d'une passerelle, mal, et vous devrez le refaire dans chaque BFF que vous écrirez.

La limite pratique est donc la suivante : si une responsabilité est la même pour chaque client, elle appartient à la passerelle. Si elle change par frontend, elle appartient au BFF.

Le BFF et la passerelle API travaillant ensemble

Dans les systèmes de microservices réels, on choisit rarement l'un ou l'autre. On utilise les deux, en couches. La passerelle se situe en périphérie. Les BFF se situent derrière elle.

Un flux de requête typique ressemble à ceci :

1. Le client mobile envoie une requête avec son jeton d'authentification.
2. La passerelle API valide le jeton, applique les limites de débit, enregistre la requête pour l'observabilité, puis la route vers le BFF mobile.
3. Le BFF mobile appelle le service produit, le service d'inventaire et le service de tarification, agrège les résultats, élague la charge utile pour ne garder que ce dont l'écran mobile a besoin, et renvoie une seule réponse.
4. La passerelle transmet la réponse au client.

L'architecture de référence de Microsoft pour ce modèle fait exactement cela : une passerelle de gestion API gère l'autorisation, la surveillance, la mise en cache et le routage, puis transmet aux services BFF spécifiques au client exécutés comme des fonctions serverless, qui appellent les microservices sous-jacents.

Chaque couche fait ce qu'elle sait faire le mieux. La passerelle gère les politiques qui doivent être uniformes. Le BFF gère la forme qui doit être spécifique. L'équipe frontend déploie des changements à son BFF sans toucher à la configuration de la passerelle, et l'équipe plateforme resserre une limite de débit sans redéployer aucun BFF.

Cette relation de superposition est similaire à la façon dont une passerelle coexiste avec d'autres infrastructures plutôt que de les remplacer. Une passerelle n'est pas un équilibreur de charge (passerelle API vs équilibreur de charge) et pas non plus un maillage de services (maillage de services vs passerelle API) ; chacun gère une couche distincte du chemin de la requête, et un BFF est simplement une couche distincte de plus. C'est le même principe derrière la connectivité basée sur les API (API-led connectivity) : donner à chaque couche une tâche claire et la laisser ne faire que cela.

Tableau de décision : BFF vs passerelle API

Lisez ceci comme une question de routage des responsabilités. Ce qui est identique pour tout le monde va dans la passerelle. Ce qui est différent par frontend va dans le BFF. Lorsqu'une responsabilité concerne les deux (vous voulez une authentification centrale mais aussi un formatage de charge utile par client), c'est le signal pour exécuter les deux couches, et non pour choisir un camp.

Quand utiliser l'un ou l'autre

Utilisez une passerelle API lorsque vous avez plusieurs services et que vous avez besoin d'un endroit unique et cohérent pour appliquer l'authentification, la limitation de débit et le routage. Presque tous les systèmes de microservices en tirent parti. Si vous avez plus d'une poignée de services exposés aux clients, vous voulez une passerelle avant toute autre chose.

Utilisez un BFF lorsque différents clients ont des besoins significativement différents du même backend, et qu'une API partagée à usage général est devenue un goulot d'étranglement. Déclencheurs courants, selon les directives de Microsoft :

• Un backend partagé demande un effort de maintenance considérable car il dessert des frontends concurrents.
• Vous continuez à personnaliser un backend à usage général pour s'adapter à plusieurs interfaces.
• Les applications mobiles et web ont des besoins en données et en performances véritablement divergents.

Sautez le BFF lorsque toutes vos interfaces effectuent des requêtes identiques ou similaires, ou lorsqu'une seule interface communique avec le backend. Un BFF ajoute un saut réseau, plus de services à déployer, et probablement une certaine duplication de code entre les BFF. Si une seule API partagée sert bien tous les clients, un BFF est une surcharge dont vous n'avez pas besoin. Microsoft note qu'une couche GraphQL avec des résolveurs par frontend peut également éliminer le besoin d'un BFF séparé, puisque les clients demandent exactement les champs qu'ils souhaitent.

Utilisez les deux lorsque vous exécutez des microservices à grande échelle : la passerelle pour une politique uniforme en périphérie, les BFF derrière elle pour la mise en forme spécifique au client. C'est l'état final courant, et non un état exotique.

Erreurs courantes

• Placer l'authentification et la limitation de débit dans le BFF. C'est l'erreur principale. Les préoccupations transversales appartiennent à la passerelle. Dupliquez-les à travers les BFF et vous obtenez une dérive : le BFF mobile applique une politique, le BFF web une autre, et votre posture de sécurité devient accidentellement incohérente.
• Laisser le BFF devenir un second monolithe. Un BFF est censé être petit et axé sur une seule expérience. Lorsque les équipes y entassent de la logique métier partagée, il redevient un backend à usage général et vous réintroduisez le goulot d'étranglement exact que le modèle était censé supprimer.
• Utiliser une passerelle comme un BFF. Certaines équipes ajoutent des règles de transformation de requêtes spécifiques au client directement dans la configuration de la passerelle pour éviter de construire un BFF. Cela fonctionne à petite échelle, mais la passerelle est gérée de manière centralisée, de sorte que l'équipe frontend dépose désormais des tickets auprès de l'équipe plateforme pour chaque ajustement spécifique au client. Vous avez couplé les mauvaises équipes.
• Construire un BFF lorsqu'un seul client existe. Si vous avez une seule application web et aucun autre client à l'horizon, un BFF est prématuré. Déployez l'API partagée. Ajoutez le BFF lorsqu'un second client divergent arrive réellement.
• Oublier le contrat. Chaque BFF et chaque route de passerelle expose une API. Chacun nécessite un contrat défini, des tests et une documentation, comme toute autre API. Omettez cela et votre couche BFF « mince » devient une boîte noire non documentée contre laquelle personne en dehors de l'équipe propriétaire ne peut s'intégrer. Voir qu'est-ce qu'un contrat API pour comprendre pourquoi cela est important.

Où Apidog s'insère

Qu'une requête transite par une passerelle API, un BFF ou les deux, chaque couche expose un contrat API. Apidog est l'endroit où vous concevez, testez, simulez et documentez ces contrats. Il ne construit pas, n'héberge pas et ne remplace pas une passerelle ou un BFF ; il vous offre un espace de travail unique pour les surfaces API qu'ils exposent.

Concrètement :

• Conception : modélisez la réponse agrégée du BFF ou les points d'terminaison routés de la passerelle en mode schema-first dans le concepteur visuel, puis générez OpenAPI pour que vos équipes frontend et backend puissent construire leurs applications.
• Simulation : créez une simulation intelligente du BFF afin que l'équipe mobile puisse développer ses écrans avant même l'existence des services en aval du BFF. C'est le flux de travail API-first qui rend possible le travail parallèle frontend et backend.
• Test : construisez des scénarios de test automatisés qui appellent les points d'terminaison exposés par la passerelle exactement comme le ferait un client réel, en validant l'authentification, les codes de statut et la forme de la charge utile agrégée.
• Documentation : publiez une documentation interactive pour chaque BFF et route de passerelle afin que chaque équipe consommatrice connaisse le contrat sans avoir à lire l'implémentation.

Le modèle que vous choisissez est une décision d'architecture. Le contrat que chaque couche expose est une constante. Apidog gère cette constante, de sorte que vos BFF et passerelles restent conçus, testés, simulés et documentés, quelle que soit la manière dont vous les connectez.

Essayez Apidog gratuitement pour concevoir et simuler vos contrats BFF et de passerelle avant d'écrire une seule ligne de code backend.

FAQ

Un BFF est-il un type de passerelle API ? Non. Ils se chevauchent en ce sens que tous deux peuvent router et agréger, mais un BFF est la propriété d'une équipe frontend et est adapté à une seule expérience client, tandis qu'une passerelle API est gérée de manière centralisée et dessert tous les clients uniformément. Un BFF se situe généralement derrière une passerelle.

Puis-je utiliser un BFF sans passerelle API ? Oui, mais vous ne devriez généralement pas le faire à grande échelle. Sans passerelle, chaque BFF doit réimplémenter des préoccupations transversales comme l'authentification et la limitation de débit, ce qui entraîne des incohérences. La passerelle les centralise afin que chaque BFF ne gère que la mise en forme spécifique au client.

Combien de BFF devrais-je avoir ? Suivez la règle de Sam Newman : « une expérience, un BFF ». Construisez un BFF séparé pour chaque frontend significativement différent. Les clients similaires maintenus par la même équipe, comme les applications iOS et Android, peuvent partager un seul BFF.

Un BFF remplace-t-il ma passerelle API ? Non. Ce sont des couches complémentaires. La passerelle applique une politique uniforme en périphérie ; le BFF met en forme les données pour un client spécifique derrière elle. La plupart des systèmes de microservices réels exécutent les deux.

Quand ne devrais-je pas construire un BFF ? Évitez-le lorsque tous les clients effectuent des requêtes similaires, lorsqu'un seul client existe, ou lorsqu'une couche GraphQL avec des résolveurs par frontend permet déjà aux clients de récupérer exactement les données dont ils ont besoin.

Où l'authentification et la limitation de débit doivent-elles être placées, dans le BFF ou dans la passerelle ? Dans la passerelle. Ce sont des préoccupations transversales qui doivent être uniformes pour tous les clients. Les placer dans le BFF duplique la logique sur chaque BFF et entraîne une dérive des politiques.