关于前端:浅谈业务中台前端设计

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

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

中台是什么

百度百科的解释比拟长篇累牍：“中台，互联网术语，个别利用于大型企业。个别是指搭建一个灵便疾速应答变动的架构，疾速实现前端提的需要，防止反复建设，达到进步工作效率目标。”
当公司倒退到肯定规模，就须要建设中台团队来进步工作效率。
在前后端拆散的合作模式下，会分为后端中台、前端中台。
对于前端中台来讲，常见的有 BFF 中台、业务中台等等。
我明天要分享的，次要是业务中台的一些教训。

中台业务的价值是什么

中台业务的大背景，诞生于“降本增效”的大号角下。
无论公司大小，无论业绩如何，“降本增效”始终都是一个不变的、能够开掘的话题。
企业须要盈利，除去增加利润之外，经营老本也是须要思考的重要局部。而人力老本或者说合作老本作为经营老本的重要组成，投入肯定的工夫和经验，产出服务或者工具，从而降低成本

做了哪些前端中台业务

大抵列举一下。

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

光看业务可能比拟含糊，上面来谈谈技术实现细节。

如何设计前端中台业务

对于如何设计前端业务，我感觉次要有几个方面须要思考

• 通用性尽可能强
• 应用方接入尽可能简略
• 文档尽可能具体、更新及时
• 接入前自测并充沛置信接入方

通用性尽可能强

通用性强其实有一个十分大的前提：前端技术栈对立、前端基建欠缺（比方前端网关、前端公布平台）。
得益于 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（如果更新十分频繁的话）
• 容易踩坑的一些敌对揭示备注

接入前自测并充沛置信接入方

在做前端中台初期，公共模块开发实现后，我会间接在业务线的我的项目中，做一次接入测试，确保链路可通、服务可用。
当服务在第一条业务线接入胜利，并且在线上胜利运行时，性能可用性已达成。
当有第二条业务线接入时，尽管接入方对链路不分明，然而作为服务提供方，曾经有了自测以及第一条业务线的接入，须要充沛置信对方，辅助接入即可

将来瞻望

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

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