浅谈业务中台前端设计

做前端中台业务一年多的时间，有一些心得体会，和大家分享分享。

中台是什么
中台业务的价值是什么
做了哪些前端中台业务
如何设计前端中台业务
未来展望

中台是什么

百度百科的解释比较言简意赅：“中台，互联网术语，一般应用于大型企业。一般是指搭建一个灵活快速应对变化的架构，快速实现前端提的需求，避免重复建设，达到提高工作效率目的。”
当公司发展到一定规模，就需要建设中台团队来提高工作效率。
在前后端分离的协作模式下，会分为后端中台、前端中台。
对于前端中台来讲，常见的有BFF中台、业务中台等等。
我今天要分享的，主要是业务中台的一些经验。

中台业务的价值是什么

中台业务的大背景，诞生于“降本增效”的大号角下。
无论公司大小，无论业绩如何，“降本增效”一直都是一个不变的、可以挖掘的话题。
企业需要盈利，除去增加利润之外，经营成本也是需要考虑的重要部分。而人力成本或者说协作成本作为经营成本的重要组成，投入一定的时间和经历，产出服务或者工具，从而降低成本

做了哪些前端中台业务

大致列举一下。

低代码加载器（xxx官网接低代码平台前端技术方案）
统一登录页（xxx账号统一过渡页业务线对接）
webComponents（webComponents版本管理方案设计）
微应用（微应用主子应用通信设计、微应用前端按配置渲染）
网关插件（xxx与yyy免登、zzz ISV优化对接文档）

光看业务可能比较模糊，下面来谈谈技术实现细节。

项目	技术
低代码加载器	@xxx/yyy-hydrate、next slug路由
统一登录页	localStorage天然域名隔离、前端网关proxy
webComponents	@xxx/direflow-component、@xxx/direflow-utils、@xxx/direflow-deploy、前端网关接口、webpack复制重命名插件
微应用	localStorage、React Context
网关插件	基于koa的BFF网关

如何设计前端中台业务

关于如何设计前端业务，我觉得主要有几个方面需要考虑

通用性尽可能强
使用方接入尽可能简单
文档尽可能详细、更新及时
接入前自测并充分相信接入方

通用性尽可能强

通用性强其实有一个非常大的前提：前端技术栈统一、前端基建完善（比如前端网关、前端发布平台）。
得益于TUYA前端技术栈统一为基于next.js的React技术栈，以及完善的前端基建，通用性强这一点有着先天的不用考虑兼容性的优势，只需要考虑“业务通用”即可。
例如在xxx业务线，有业务线A、业务线B、业务线C、业务线D、业务线E等等业务线。
在开发中台业务时，主要需要考虑：技术方案在各个业务线是否通用？

举例来说：

前端组件如何既兼容UI框架 v3，又兼容UI框架v4
网关插件是否既支持协议A，又支持协议B
若项目以微应用子应用方式下沉，主应用是否具备接入能力
微应用前端按配置渲染，context方式可以无感注入到hook及组件

使用方接入尽可能简单

前端中台设计，面向的是业务线各团队的前端提供服务。
如何让“使用方接入尽可能简单”，这个可谓是非常重要。

举例来说

低代码加载器接入：遇到next版本不一问题，需要一一统一。只有统一后，才能统一使用npm包接入
统一登录页：数据存储localStorage、配置代理即可
webComponents：初期以script脚本链接接入、后期优化为脚本实时接入和更新；组件功能尽可能收敛，减少接入方工作量
微应用：主子应用统一通信方式为foo，提供统一子应用获取应用信息npm包
网关插件：尽可能将逻辑收敛到网关插件内部，例如登录态获取、api调用、redirect等等

文档尽可能详细、更新及时

一份清晰、易用的文档非常重要。
可以帮助接入方更快速的接入，可以节约很多沟通时间。
如果链路较为复杂，尽可能提供一份清晰的链路图（推荐使用mermaid绘制链路图）。

文档主要考虑几个方面

api / props 说明
清晰的demo
文字少一点，一图胜千言
链路图、架构图、原理图
changelog（如果更新非常频繁的话）
容易踩坑的一些友好提醒备注

接入前自测并充分相信接入方

在做前端中台初期，公共模块开发完成后，我会直接在业务线的项目中，做一次接入测试，确保链路可通、服务可用。
当服务在第一条业务线接入成功，并且在线上成功运行时，功能可用性已达成。
当有第二条业务线接入时，虽然接入方对链路不清楚，但是作为服务提供方，已经有了自测以及第一条业务线的接入，需要充分相信对方，辅助接入即可

未来展望

除去上述的很多方法论或者说经验之外，想要做好业务中台前端设计，还有很多事需要做：

增强服务意识和沟通能力
拥抱新技术、拓宽技术栈
提升代码通用性、内聚性