【大咖分享】BFF在千寻位置网前端的落地和演进

掌门教育前端技术分享会第一期已于1.23号落幕，如下为大咖讲师们现场演讲的整理稿，感谢你们的支持：

讲师介绍

唐兵，前端技术专家，来自千寻位置网业务中台前端团队 负责团队电商相关业务开发，团队BFF层技术负责人 团队平常工做内容，主要对公司门户、电商、营销、分销等业务提供前端支持，业务覆盖 PC、H五、App、小程序、NodeJS 等各类技术场景。

如下为唐兵同窗的部分精彩演讲内容：

BFF的历史演化进程

前端BFF层，咱们大概经历了四个阶段：

1. serverAPI：后端直接将接口暴露给前端开发，进行业务调用，也是咱们前端开发最常接触到的模式。
2. internalRest：后端同窗在底层service数据接口的基础上，进行业务页面逻辑聚合处理，再透传到前端进行页面数据渲染。
3. Apoll-Graphql：业务接口聚合结构化、模块化，目前这块是由咱们千寻位置网前端开发同窗牵头；这里的背景是，目前公司后端服务基本都是采用微服务化开发，接口数据都是原子化交付，
4. Apoll-Federation：在Graphql基础上，作支撑服务的拆分，以提供更好的开发体验

目前，千寻位置网前端处于第三向第四阶段过渡

InternalRest

对应后端开发同窗来讲，强耦合页面展现逻辑的开发方式来开发API，开发体验不好、有干扰，internalRest能够帮助开发同窗作开发分层，把拼接数据这一层的逻辑从数据的核心模块里面剥离出去，后端的数据模型能够跟具体页面逻辑无关；

这种方式在先后端分离的开始阶段，确实会极大的加速业务开发，但随着业务的不断发展，不少非业务模型的必要字段难以维护；这就是典型的【数据的生产者和数据的消费者之间的工做边界不清晰】

Apoll-Graphql

为何选择graphql，

1. graphql容许前端开发同窗能够自定义数据字段，它提供配置式的方式来定义、裁剪数据结构，前端同窗无需写冗余代码
2. graphql能够很是方便的帮助咱们，实现业务页面的数据聚合，好比咱们一个商城系统，有商场列表、购物车、公告信息等等，这里咱们能够经过一个graphql的定义接口，就拿到全部数据，减小接口请求数量
3. 结合graphql强制要求描述数据类型，咱们能够很是清晰、直观的理解每个数据的具体含义

NestJs-Graphql

为何推荐使用NestJs：

咱们在实际的项目开发中发现，在开发server层时，强类型语言的开发方式对数据更友好，NestJs相对于Koa来讲，对数据类型支持更好，另外NestJs提供了不少通用的模块功能，好比使用Guard作用户校验，filter作数据异常的处理等等

Apoll-Federation

目前千寻位置网，不少的业务场景下面，前端BFF层程序并非直接对外暴露的，而是经过web-gw（网关）来作分发，经过网关层再来作接口聚合，这样万一辈子产某一个服务发生错误异常，仍然能够保证咱们其它的服务不会受影响

Gateway是经过数据schema定义来聚合具体业务数据，而且它能够支持跨项目式schema格式获取，能够极大的方便咱们跨项目开发

Gateway除开项目代码内定义schema结构外，还提供了远程push-pull方式拉取schema结构，不过Apollo官方未提供独立部署的解决方案，须要咱们本身开发一套 Schema 集成系统，千寻位置网本身也实现了一套，这个就比较因人而异了

更多精彩内容，欢迎关注