BFF est une architecture web, le nom complet est Backends For Frontends, qui est le backend servant le frontend. Le terme vient d'un article de Sam Newman : Pattern : Backends For Frontends . BFF fait généralement référence à l'ajout d'une couche intermédiaire entre l'extrémité avant et l'extrémité arrière. Pourquoi ajouter une couche BFF entre le front end et le back end ?
L'informaticien David Wheeler a dit un jour : All problems in computer science can be solved by another level of indirection.Tous les problèmes informatiques peuvent être résolus en ajoutant une couche. Par conséquent, la scène qui doit utiliser BFF doit être que les modèles de développement front-end et back-end ordinaires ont rencontré des problèmes. Par exemple, l'article de Sam Newman décrit le scénario où BFF résout plusieurs terminaux d'affichage.
Problème d'affichage multi-terminal
Lorsque le système a été développé pour la première fois, seule la conception de la page Web du PC était prise en compte et l'API côté serveur était destinée à la page Web du PC. Mais plus tard, avec l'essor de l'Internet mobile, le terminal mobile est devenu populaire. Il a été décidé de développer une application mobile basée sur le serveur d'origine et de réutiliser l'API précédente. Cependant, l'API d'origine a été conçue pour le terminal PC et n'a pas répondre aux besoins du terminal mobile.
- Les exigences du terminal PC ne sont pas nécessairement les mêmes que celles du terminal mobile, et l'interface existante ne peut répondre à toutes les nouvelles exigences du terminal mobile.
- Les performances du terminal PC sont élevées et il peut demander plusieurs interfaces simultanément ou effectuer un traitement de données complexe, mais les performances du terminal mobile sont faibles. Si les mêmes interfaces multiples sont utilisées et que les données sont assemblées par le frontal, l'affichage de la page peut être retardé et bloqué. .
- L'écran du côté PC est plus grand et le contenu d'affichage est plus complet. Cependant, l'écran du terminal mobile est petit et le contenu affiché est moindre. De plus, il n'est pas facile d'obtenir certaines données et le backend doit appeler de nombreux services. Si le terminal mobile réutilise l'interface du terminal PC, certaines données inutiles seront acquises et transmises, ce qui non seulement consomme les ressources du serveur, mais gaspille également la bande passante du réseau.
De plus, avec l'évolution de la technologie et les besoins des utilisateurs, il existe de plus en plus de terminaux à écran différents.Non seulement les terminaux Android et IOS seront distingués sur les téléphones mobiles, mais il y aura également des terminaux de tablettes PC, des pages Web mobiles, des sites Web sur PC. pages et pages Web du PC.App fin et ainsi de suite. Les conceptions de page de ces terminaux sont différentes et les exigences en matière de données sont également différentes. En supposant que nous réutilisions le même serveur et la même interface API, s'il y a une scène qui ne répond pas aux exigences, ajoutez l'interface et ajoutez des champs, puis avec le développement et l'itération de ces différents clients, le serveur deviendra volumineux, gonflé et inefficace . De plus, la même interface est fournie pour trop d'appels frontaux, impliquant trop de logique, et la complexité devient de plus en plus élevée.
Par conséquent, une meilleure solution consiste à découpler l'affichage du serveur, le serveur n'étant responsable que de la fourniture de données et un terminal d'affichage dédié étant responsable de l'activité d'affichage frontal. Le côté affichage ici est la couche BFF.
Différences dans les modes d'affichage pour différents scénarios d'entreprise
Dans certaines entreprises, il n'y a qu'un seul type de client, mais dans différents scénarios, les modes affichés sont différents. Par exemple, dans la pratique BFF de Meituan , les modules d'affichage des étagères d'achat groupé dans différentes industries sont différents.Il s'agit de deux ensembles de logique de produit définis indépendamment, et ils seront itérés séparément.
Dans ce scénario d'entreprise, bien qu'il s'agisse du même client, l'entreprise est différente et le format et le type de données requis sont également différents, de sorte qu'il rencontre un problème d'interface similaire à l'affichage multi-terminal ci-dessus.
besoins à cycle de vie court
Une autre situation concerne les exigences de cycle de vie court rencontrées par l'équipe Xianyu . Dans les scénarios commerciaux courants, le serveur est normalement et de manière stable développé de manière itérative. Mais occasionnellement, il y aura des activités opérationnelles spéciales, qui sont de courte durée et peuvent ne durer que quelques jours.
Si ce n'est que pour les activités de ces quelques jours, il est coûteux et inefficace d'ouvrir une nouvelle API, de déboguer en commun, voire de modifier à chaque fois la logique du serveur d'origine. Si une couche de BFF est ajoutée afin que le frontal puisse obtenir directement des données, le développement et le débogage conjoint deviendront beaucoup plus faciles.
besoins d'intégration d'entreprise
在某些情形下，业务后端和需求比较复杂，例如这篇文章涉及到的场景，有一个Moments App,包含了像用户管理，关系管理，信息，头像，点赞等多种多种后端微服务。这些服务在前端展示的逻辑耦合性较强。比如有些需要串行处理，例如得到服务1的结果才可以调用服务2；有些则可以并行处理。而数据合并和整理的逻辑额较为复杂。
图片来源：跨平台架构：如何设计 BFF 架构系统？
网易云音乐也使用BFF进行微服务的调度以及数据的组装和适配。
这时候可以设立一个BFF层，作为一个数据整合服务，将调用不同微服务接口，与数据处理的复杂逻辑都在BFF端中实现，降低了前端的复杂度，也提高了响应效率。
处理部分展示相关的业务
在使用了BFF之后，部分页面展示相关的业务逻辑可以抽象出来，交由BFF端处理。
例如数据导出Excel下载服务，输入导入Excel上传服务。BFF层可以接收用导入的Excel，解析并处理表格数据，然后提供给服务端。在导出时，也可以调用服务端API获取数据，由BFF端整合提供给前端下载。在这种情形下，服务端只需要提供一个展示接口，就可以满足页面展示和导出两种不同格式的展示需求。导入也是同理。而且假设表格与页面展示要求的数据格式不同，例如导入时部分字段值需要作转换，那么也可以由BFF端处理这种差异。
BFF的类型
BFF本身仅仅是一个概念，实现方式有多种，在实际中我们要根据不同的场景选取不同的方案。按照大类分，主要有单一BFF和多端BFF。
单一BFF
单一的BFF主要对接服务端，根据展示服务的需求组装数据提供给每个端或者每种业务进行展示。
很多单一BFF都会用到GraphGL，他是由Facebook开发的数据查询工具。通过该工具，可以将不稳定的数据组装部分从稳定的业务数据逻辑中剥离，使数据控制逻辑前移，开发模式由“下发数据”转变成“取数据”的过程。
例如美团，闲鱼，网易云音乐等的BFF，都提供了按需查询能力，一个BFF对接多种客户端或者多种业务的需求。下图是美团使用的BFF架构设计。
图片来源：GraphQL及元数据驱动架构在后端BFF中的实践
多端BFF
多端BFF是指每种业务或者每种客户端采用自己独立的BFF层，这样每种客户端的服务更加灵活，不同的BFF端对于展示服务解耦性更高。
前端BFF与后端BFF
从技术上分，BFF又可以分为前端BFF和后端BFF。即BFF层由前端团队主导或者后端团队主导。前端团队的BFF一般使用Node.js，后端团队则会使用Java或者其他服务端语言。
如果使用前端BFF，可以实现谁使用谁开发，一定程序生避免了前后端实现的上不必要的沟通成本。但需要前端团队有一服务端开发经验，对前端团队的技术建设有较高需求。但是前端也能更深入的接触业务逻辑，对于重展示的业务需求有一定优势。例如淘宝的实践：大淘宝技术行业FaaS化实战经验分享。
传统接口与按需查询
传统接口模式即正常开发接口，固定入参和返回数据格式，供前端调用。按需查询模式即前端调用接口时指定需要哪些数据，前端自主进行按需查询。GraphQL即是使用按需查询的模式。
BFF的其他特点
与ServerLess集成
使用前端BFF时，前端开发可能缺乏运维经验，而且在高可用，并发性等问题上可能会遇到挑战。如果结合Serverless实现自动扩容，弹性伸缩等功能，可以解决一些BFF的问题。
阿里云的云原生团队介绍了这一方法：基于函数计算的 BFF 架构（图片来源）
BFF与网关
网关可以提供路由，认证，监控，日志等服务。网关可以与BFF集成在一起，也可以作为独立的一层来实现。如果业务复杂，还可以在不同的BFF上层配置不同的网关。
这篇文章介绍了在不同场景下，BFF层与网关的应用。 微服务架构：BFF和网关是如何演化出来的？（图片来源）
BFF的优势
通过上面的的各种问题和场景，相信我们已经知道了BFF可以解决很多场景的问题，这里总结一下BFF的优势：
- 服务端对数据展示服务进行解耦，展示服务由独立的BFF端提供，服务端可以聚焦于业务处理。
- 多端展示或者多业务展示时，对与数据获取有更好的灵活性，避免数据冗余造成消耗服务端资源。
- 对于复杂的前端展示，将数据获取和组装的负责逻辑在BFF端执行，降低前端处理的复杂度，提高前端页面响应效率。
- 部分展示业务，可以抽象出来利用BFF实现，对于服务端实现接口复用。
- 降低多端业务的耦合性，避免不同端业务开发互相影响。
- 其他优势，包括数据缓存，接口安全校验等。
参考
- Pattern: Backends For Frontends
samnewman.io/patterns/ar… - GraphQL及元数据驱动架构在后端BFF中的实践 美团技术团队
mp.weixin.qq.com/s/mhM9tfWBl… - 高效研发-闲鱼在数据聚合上的探索与实践 闲鱼技术
mp.weixin.qq.com/s/9P_16cNEF… - 跨平台架构：如何设计 BFF 架构系统？
www.jianshu.com/p/bfc652bac… - 什么是 GraphQL？ 知乎
www.zhihu.com/question/26… - Série DDD Article 10 : Architecture BFF
www.cnblogs.com/arrowolf/ar… - Architecture BFF basée sur Function Computing Alibaba Cloud Cloud Native
juejin.cn/post/684490… - Architecture microservice : comment BFF et les passerelles ont-elles évolué ?
juejin.cn/post/684490… - Musique en nuage basée sur GraphQL Pratique de la construction BFF Équipe de technologie de la musique en nuage Netease
juejin.cn/post/718201… - Partage d'expérience pratique FaaS de l'industrie de la technologie Big Taobao
juejin.cn/post/714352…