BFF避坑指南

cd66

BFF —— Backends for frontends（办事于前真个后端），是为了让后端API知足不同的前端使用场景，而演进出来的一种模式。BFF在改良前端用户体验上起到了十分大的作用，但由于介于前端和后端之间，在落地实行过程当中很容易踩坑，在这篇文章中，咱们看看在实行BFF的过程当中可能遇到哪些“坑”。为了帮忙疾速了解前面讲到的问题，咱们先来简略回顾下BFF的由来和运用场景。
BFF的由来
跟着挪动装备的疾速开展以及产品对用户交互体验的关注度加强，先后端别离的架构模式也逐步被大少数企业所采取。在这类模式下，一致的后端API很难知足在不同场景下对用户体验的不同需要。
BFF模式应运而生，一方面BFF隔离了前端UI展现对后端API的需要，企业能够专一在后端构建中心业务才能，另外一方面，BFF按照已有的后端API，疾速知足前端在UI展现上的需要，来不停晋升用户体验；
从常识办理的角度，BFF模式让常识界限定义得更明晰，后端专一于构建业务才能，不需求斟酌前端各种场景适配的问题；而前端更关注用户体验，能够随时独立公布更新。
BFF的运用场景


面向前端
BFF为前端而生，跟着前端技术（iOS、Android、小顺序、Web等）的不停开展，不同前端对后端要求有很大差别，后端办事很难提供知足多个前真个一致接口，BFF则能够针对前真个特定需要，作出适配：
针对前端UI展现逻辑的不同，对后端API前往的数据进行裁剪和从新组织，提供面向前真个定制化格局的数据。按照前端业务需要，对后端多个API前往的数据进行聚合。对一些特定场景的数据进行缓存，进步机能，进而晋升用户体验。面向后端
BFF隔离了前端UI展现对后端API的定制化需要，能够很好地反对后端办事的演进：
从单体运用迁徙到微办事架构，后端架构的演进能够经过BFF来进行隔离，拜见《先后端别离演进：不克不及微办事，那就 BFF 隔离》。微办事架构外部的演进，微办事的拆分，也能够借助BFF来增加对前真个影响，拜见我的此外一篇文章《迭代开发中的微办事拆分》。BFF理论的三大问题
BFF模式在先后端别离的架构模式下确实有得多益处，完善隔离了先后端，貌似从此当前前端干前真个，后端干后真个，大大升高先后端之间的冲突和依赖。但是事实并不是如斯，在实行BFF的过程当中，大家依然会遇到各种问题，我总结了实行落地BFF三大常见问题如下：
问题一：反复代码
通常状况下咱们会为每个不同的前端构建一个BFF，还可能会为一些特定的场景建设BFF（如对第三方零碎提供API），不成防止地，多个BFF之间会泛起少量的反复代码，好比可能会存在相反的数据转换逻辑，相反的API数据聚合逻辑等等。
反复代码通常被以为是一种坏滋味，但在BFF这个场景下，这些反复的代码是为了某一个特定的前端办事的，因此处置这个反复要相对于小心，假如一味粗暴地去掉这些反复，颇有可能诱发某一个前端需要变动会影响到其余前端运用的状况。
假如的确有些代码反复且相对于不乱，能够尝试采用上面的办法来打消反复：
同享库，将反复的代码抽掏出来放到同享库中，不同的BFF经过依赖同享库来达到代码复用，但要斟酌哪些代码可以抽取到同享库中，能够参考我以前的文章《歼灭微办事的坏滋味 之 同享库》。将反复的代码放到后端办事中，这类办法合用于反复的代码实际承载了真正的业务逻辑，而不仅是在做简略的数据聚合和数据格局转换，那末应该把这些反复的代码下沉到指定的后端办事中。问题二：滑向ESB（Enterprise Service Bus，企业办事总线）
除了少量的反复代码，在微办事架构下，此外一个问题通常会泛起在业务演进过程当中。当新的业务需要发生时，详细要在哪一个后端办事中完成有时分不是一个很容易回答的问题，特别是不同的办事有不同的团队归属时，假如每个办事的归属团队都以为新的业务需要不是本人办事的业务范畴，最可能的后果就是让BFF担任帮助组合各个办事的功用，实现这个新的业务需要。渐渐地，BFF朝着ESB的标的目的开展，变为了集成各个微办事，对外提供新才能的两头件。
这类趋向某种水平上违抗了BFF设计的初衷，BFF为了适配前端而生，更关注解决前真个用户体验问题，而真正的业务才能应该由后端办事来承接，而不是BFF。
要解决这个问题，首先要明晰地定义每个办事的业务职责，为了不办事过量很难划分明晰界限，最开始办事尽可能不要拆得过小；此外要建设规定来处置新的需要，哪些需要属于BFF的范畴，哪些属于业务才能，业务才能应该下沉到后端办事中，假如现有办事无奈承载这类才能，能够斟酌新增办事，而不是写在BFF中。
问题三：机能问题
第三个对比常见的问题就是机能问题，置信你一定遇到过上面的场景，既然有了BFF，前真个设计开始放飞自我，能够把想展现的信息一股脑都放在一同展现，极端状况下BFF能够获得就任意办事的数据进行组合，我曾见过在一个BFF接口中调用了后端办事几十次来拼凑前端需求的数据，可想而知这个接口的机能一定很差。
为理解决这类状况带来的机能问题，通常会采取并发获得数据而后拼装的形式，这显著减少了代码完成和保护的繁杂度，往往会诱发新的问题。
因此，在实际开发过程当中要十分警觉这类问题的产生，假如一个BFF接口调用了3个以上接口，那就要警觉了，需求剖析下后端办事拆分得合分歧理，前端UI展现的数据是不是有须要放在一同，不然机能问题会逐步成为一个不成防止的问题。
小结
架构设计是经过公道的组件拆分以及定义组件之间的瓜葛，将零碎总体的繁杂性扩散到不同的组件中，在更低的维度上解决问题，分而治之。BFF在先后端别离的架构模式下隔离了前端和后真个关注点，特别是在多个前端或第三方的状况下，BFF都是十分好的选择。但是，在实行过程当中，依然要时辰警觉，明白BFF设计的初衷，防止因引入BFF而带来了更多的问题。
参考材料
Pattern: Backends For FrontendsBFF @ SoundCloud文/Thoughtworks 麻广广