Parlons pattern: BFF
Tags: webdev, microservices, frontend, architecture
Published: 2024-06-19 15:23:16

Aujourd'hui, nous allons parler pattern.
Il se présente comme le meilleur ami des développeurs (BFF, you got it ? 😶), mais on l'utilise souvent sans le connaître.
Penchons nous sur le **Backend For Frontend** !

## Pourquoi ce pattern ?

En développant des applications web, on est souvent confronté à une volonté de **récupération de données**, majoritairement **provenant d'API**...
Et en travaillant dans un **contexte MACH** (Micro Services, API-first, Cloud Native, Headless), où ces données vont **provenir de plusieurs sources**, c'est souvent l'application Frontend qui va se charger de leur récupération et manipulation.

![Une application Frontend appel plusieurs API](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/odqz3lwkdz98zulx6bef.png)

Tant que l'**application** reste **simple**, on pourrait se **contenter de ce fonctionnement**.

Mais on imagine bien que plus l'**application gagne en cas d'usage**, plus on va se retrouver avec beaucoup de **logique de transformation, d’agrégation**...
Et ce, dans **chaque application Frontend du périmètre**: mobile, web, embarquée...

Dans notre exemple précédent, on imagine de multiples API, mais on pourrait aussi imaginer un Backend unique !

Et dans ce cas, la donnée exposée aux Frontend se verra de plus en plus générique, de moins en moins spécialisée aux usages des Frontend... Et on se retrouvera avec les même problématiques: transformation, aggregation etc.


![De multiples Frontend appellent un backend unique](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/509duyatv3yuz37kiyuf.png)

_Est-ce vraiment ce que l'équipe souhaite ?_

Dans le cas où la réponse serait négative, continuons la (re)découverte de ce pattern !

## Qu'est ce qu'un BFF ?

Un Backend For Frontend, c'est donc une **couche** qui se place **entre le Frontend et les API**.
Au lieu de laisser le Frontend **faire les appels** aux différentes API et **agréger**, on se contente de faire un appel au **BFF qui va lui faire le travail**.
On déplace le travail côté serveur en évitant de surcharger le navigateur avec des tâches à faible valeur ajoutée.

Le BFF va finalement retourner une **réponse prête à être consommée** par les Frontend du même type.
Par exemple, il y a de fortes chances pour que la donnée sur **iOS** et **Android** soit utilisée de la même manière, **un BFF pour ces deux applications** pourrait suffire.

## Comment l'implémenter ?

Partons d'un existant où tous vos Frontend appelleraient un ensemble d'API. Chaque Frontend va porter sa logique de manipulation des données.

![L'existant: de multiples frontend et une multitude d'API](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/78qs1z6nicv8ryfbt8hd.png)

Nous allons introduire une couche supplémentaire côté mobile et côté web, notre BFF.

Au passage, nous profiterons ainsi de facilités d'évolution pour nos applications mobiles, car **moins soumises au redéploiement sur les stores**.

![La cible: deux BFF, un pour le mobile et un pour le web](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/646qtmdfws0lut8y1gwy.png)

## Quelles différences avec l'API Gateway ?

On pourrait se poser la question car les deux solutions ont le même esprit: une **couche passerelle** entre des applications consommatrices de données, et des services qui la propose.

Les grandes différences se situent :

- Sur le périmètre adressé

Là où l'**API Gateway** va servir de **point unique**, on l'a vu, le **BFF** va être **dédié pour un seul type de client**: mobile, web, console de jeu... Car chaque **type de client** peut avoir **sa spécificité** en terme de présentation de donnée, de gestion d'erreurs, d'authentification etc

- Sur les responsabilités

Techniquement, vous allez pouvoir **gérer du cache**, du **rate limiting**, de la **monétisation** côté serveur... Mais **ce n'est vraiment pas le but du BFF** !
Il faudrait plutôt privilégier des solutions d'**API Gateway / Management** comme [Gravitee](https://www.gravitee.io/).
Et donc vous l'avez compris, on peut tout à fait combiner BFF et API Gateway, ils n'ont pas les mêmes usages.

**_Ça pourrait mériter un article dédié !_**

![API Gateway vs BFF](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i571i0a6klovegray4ox.png)


## Comment se décider ?

_Voyons quelques avantages et inconvénients à l'usage du pattern BFF._

- + Résilient aux changements d'API
- + Gestion des erreurs provenant des API, retransmission dans un format intéressant pour les Frontend
- + Une donnée présentée sur mesure
- - Nécessité d'avoir + de compétences fullstack dans l'équipe
- - Maintient d'une couche supplémentaire

La question intéressante à se poser pour savoir si l'implémentation d'un BFF est nécessaire, serait:

> Est-ce que j'ai besoin de proposer une expérience différentes aux utilisateurs selon le type d'application ?

Prenons l'exemple d'une console de salon.
Il y a de grande chance pour que l'**expérience utilisateur** souhaitée soit **différente** selon l'application utilisée: dashboard web, application mobile, interface de la console...
La donnée sera présentée différemment, l'authentification sera différente...
Le pattern BFF aurait tout à fait sa place dans ce contexte.

Par contre, si vous développez une **application unique**, avec un **scope réduit**, la **complexité** induite par une nouvelle couche dans votre architecture ne serait **pas nécessaire**.

## Quelques réflexions supplémentaires...

Réfléchir au pattern BFF, c'est déjà avoir **envisagé les micro-services** comme une solution potentielle.

_Est-ce vraiment le cas, quels seraient les cas d'usages parfait pour ce besoin d'architecture ?_

_Est-ce que j'ai plutôt intérêt à partir sur le développement d'un monolithe modulaire ?_

_Comment mettre en place une API Gateway dans mon architecture ?_

## Ressources

- [The API gateway pattern versus the Direct client-to-microservice communication](https://learn.microsoft.com/fr-fr/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern)
- [What Is A Backend For A Frontend (BFF) Architecture Pattern](https://www.youtube.com/watch?v=SSo-z16wEnc&ab_channel=GoingHeadlesswithJohn)
- [Backend for Frontend Pattern in Microservices](https://www.youtube.com/watch?v=GCx0aouuEkU&ab_channel=ArpitBhayani)
- [Backend for frontend (BFF) pattern— why do you need to know it?](https://medium.com/mobilepeople/backend-for-frontend-pattern-why-you-need-to-know-it-46f94ce420b0)
- [7 Key Lessons I Learned While Building Backends-for-Frontends
](https://wundergraph.com/blog/7-key-lessons-i-learned-while-building-bffs)
- [Pattern: API Gateway / Backends for Frontends](https://microservices.io/patterns/apigateway.html)

----

Je suis Baptiste FAMCHON, Tech Lead spécialisé frontend chez Claranet.
J'écris régulièrement sur [dev.to](https://dev.to/claranet) et [LinkedIn](https://www.linkedin.com/in/baptiste-famchon/) à propos de sujets autour du web et de l'artisanat logiciel.

Chez [Claranet](https://www.claranet.com/), nous vous accompagnons aussi dans vos réflexions de modernisation SI, d'infrastructure cloud, de sécurité et de développement web.

N'hésitez pas à nous contacter ! 🚀