BFF——服务于前端的后端

Web 1.0

第一代Web架构很简单，纯后端网页渲染；就是客户端每次向服务器请求都会返回一个特定的html页面，js都没啥大用场。我学生时代流行的JSP就属于这个范畴。后来上班了，发现厂里的操作更风骚，用的是string拼接html的动态渲染技术，当时极为震惊。

Web 2.0

时间又到了10年前，手机业务开始蓬勃发展；受限于网络传输，由后端反复送html到前端（后端渲染）的技术很难适应新的业务场景。

这时候聪明的小伙子们想到了将数据格式转化成JSON，并通过api调用提供给前端使用——前后端解耦。

Web 2.0

此后的变化是一系列的JS前端框架方兴未艾；得益于技术演进，前后端技术正式分离，Web交互空前丰富。

微服务时代

前端在剧烈演进，后端也悄然发生着变化：微服务、中台战略这类词汇充斥在各类技术架构中。

Micro-services

客户端与微服务交互成为了新的考量。应对微服务的方案很多：

• API Gateway

比较直观的方案就是利用api网关分发请求：

API Gateway

• CORS

第二个想到的是前端跨域请求。前端分别向不同微服务发出请求，再将回调数据在Flux层处理后反映在DOM上。

CORS

---

上述两种方案，在业务权责上有明显偏重。怎么看出来呢？看数据的组装、聚合、裁剪放在哪一块就行了。

做过前端的小伙伴一般都能理解这一点：网页各个子模块的展示是很琐碎的：有时是一个单一字符串的显示，有时是多表联结的表单渲染。

方案一中，后端有时需要准备力度很细的数据返回，这个就要求前后端频繁沟通。而另一些场景，后端又需要构造各种级联表单，以致微服务之间调度频繁；而微服务的本质是清晰的界限上下文，因此在某些场景下这种设计会导致领域建模变得较为复杂。

再说一下方案二。前端分层和建模是最近比较流行的设计趋势，有一些流派甚至喊出了前端DDD，我也挺喜欢这种趋势的。说实在，后端编写接口挺麻烦的，不如提供一些粗粒度的api，交由前端酌情处理。只是传输负载可能会比较大；还有就是在多平台开发时，各平台需要重复组织数据，这就显得很冗余了。

BFF

有没有更优雅的解决方式呢？嗯，不如将组装、聚合、裁剪这部分业务单独拎出来，组成一个叫Back-end for Front-end的中间层。

BFF

没有什么是加一个中间层解决不了的，如果有，就加两个…… ——鲁迅

BFF就是老生长谈的中间层概念，是上述一二方案的折衷解法。实现上没太大限制，就是一层nodejs，能做请求转发和数据转化即可。Nodejs既配合了前端技术栈，也更适应向微服务的并发请求。我自己的项目就是在Node上跑了一个Graphql的服务；也可以做成对前Restful、对后RPC的实现；还可以在BFF上加cache、鉴权等等操作，具体可以根据自身需求改造。

BFF优缺点

---

回顾完前端演化史，我们再来分析BFF利弊。

BFF作为中间层，优点是：

• 前后端彻底分离，即便是后期有微服务迁移，也不需改动前端代码

跳槽是每个人的职业生涯中都要经历的过程，不论你是搜索到的这篇文章还是无意中浏览到的这篇文章，希望你没有白白浪费停留在这里的时间，能给你接下来或者以后的笔试面试带来一些帮助。

也许是互联网未来10年中最好的一年。WINTER IS COMING。但是如果你不真正的自己去尝试尝试，你永远不知道市面上的行情如何。这次找工作下来，我自身感觉市场并没有那么可怕，也拿到了几个大厂的offer。在此进行一个总结，给自己，也希望能帮助到需要的同学。

面试准备

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

面试准备根据每个人掌握的知识不同，准备的时间也不一样。现在对于前端岗位，以前也许不是很重视算法这块，但是现在很多公司也都会考。建议大家平时有空的时候多刷刷leetcode。算法的准备时间比较长，是一个长期的过程。需要在掌握了大部分前端基础知识的情况下，再有针对性的去复习算法。面试的时候算法能做出来肯定加分，但做不出来也不会一票否决，面试官也会给你提供一些思路。