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.
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.
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.
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.
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.
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é !
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
- What Is A Backend For A Frontend (BFF) Architecture Pattern
- Backend for Frontend Pattern in Microservices
- Backend for frontend (BFF) pattern— why do you need to know it?
- 7 Key Lessons I Learned While Building Backends-for-Frontends
- Pattern: API Gateway / Backends for Frontends
Je suis Baptiste FAMCHON, Tech Lead spécialisé frontend chez Claranet.
J'écris régulièrement sur dev.to et LinkedIn à propos de sujets autour du web et de l'artisanat logiciel.
Chez Claranet, 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 ! 🚀
Top comments (0)