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

·  阅读 1162

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

讲师介绍

唐兵,前端技术专家,来自千寻位置网业务中台前端团队 负责团队电商相关业务开发,团队BFF层技术负责人 团队日常工作内容,主要对公司门户、电商、营销、分销等业务提供前端支持,业务覆盖 PC、H5、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-Graphql

为什么推荐使用NestJs:

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

Apoll-Federation

目前千寻位置网,很多的业务场景下面,前端BFF层程序并不是直接对外暴露的,而是通过web-gw(网关)来做分发,通过网关层再来做接口聚合,这样万一生产某一个服务发生错误异常,仍然可以保证我们其它的服务不会受影响

Gateway是通过数据schema定义来聚合具体业务数据,并且它可以支持跨项目式schema格式获取,可以极大的方便我们跨项目开发

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

更多精彩内容,欢迎关注

分类:
前端
标签:
收藏成功!
已添加到「」, 点击更改