Le BFF (Backend For Frontend) est un pattern de conception dont on trouve des traces il y a déjà une dizaine d’années. Cependant, il reste encore confidentiel. Dans cet article, on vous parle de tout ce qu’il y a a savoir sur le sujet et on vous donne nos conseils pour faire de ce pattern votre meilleur ami (BFF en anglais 😎)
Cas d’utilisation
Vous êtes responsable d’une architecture ayant plusieurs devices (Web/Mobile) ou exposez des APIs a plusieurs services tierces ?
L’architecture cible standard/naïve est la mise en place d’une API générale qui mutualise les besoins. La mutualisation est une bonne chose, encore faut-il ne pas le faire trop tôt. Prenons le cas de deux interfaces utilisateurs : une en web et l’autre en mobile, les deux se veulent très similaire. Cependant, une interface mobile se basant sur un écran mobile (plus petit par définition), la limitation du nombre de connexion et l’optimisation de la bande passante demande de limiter les datas.
Un second point est qu’une API générale est le Single Point of Failure et un point d’étranglement pour les mises à jour. Le Backend For Frontend peut répondre à cette problématique :
Définition du Backend For Frontend
L’architecture BFF est fortement couplée à l’expérience utilisateur. De manière générale chaque API est maintenue par la même équipe que celle de l’interface utilisateur. Cela permet d’adapter l’API au besoin de l’IHM et réduit l’adhérence du delivery.
Alors faut-il un BFF par type de device (Android/Apple) ? Nous vous conseillons d’en faire autant par équipe.
Pitfall (les pièges à éviter)
Attention à l’utilisation du « reuse ». La multi-utilisation est toujours attirante, mais si vous constatez une trop grosse similarité de code dans le flux de donnée, et que ceci est hautement localisé, vous venez peut-être de découvrir un découpage en service de votre application ! Évidemment, il n’y a pas de recette miracle et il faut savoir prendre des décisions, si vous sentez que votre API a trop de paramètres, il faut savoir revenir en arrière.
Le Backend For Frontend est une solution (mais sans être un silver bullet), pour diminuer la friction sur le delivery d’application ayant plusieurs IHM (plusieurs devices). Même si cela va à l’encontre de la croyance générale de la factorisation du code, cette solution est un moyen qui vous permettra d’améliorer votre time to market et réduire les conflits entre les équipes.
