浅谈业务中台前端设计

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

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

中台是什么

百度百科的解释比较言简意赅:“中台,互联网术语,一般应用于大型企业。一般是指搭建一个灵活快速应对变化的架构,快速实现前端提的需求,避免重复建设,达到提高工作效率目的。”
当公司发展到一定规模,就需要建设中台团队来提高工作效率。
在前后端分离的协作模式下,会分为后端中台、前端中台。
对于前端中台来讲,常见的有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(如果更新非常频繁的话)
  • 容易踩坑的一些友好提醒备注
接入前自测并充分相信接入方

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

未来展望

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

  • 增强服务意识和沟通能力
  • 拥抱新技术、拓宽技术栈
  • 提升代码通用性、内聚性
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
Odoo 是一款开源的企业资源规划软件,它提供了完整的后台管理系统和前端展示系统,同时也支持文件的存储和下载。下面就针对 Odoo 的后台与前端文件(附件)的存储与下载进行浅谈。 1. 后台文件存储 Odoo 的后台文件存储主要是通过模型字段来实现的。在模型中,我们可以定义一个二进制字段(binary field),用来存储文件的二进制数据。例如,我们可以在产品模型中添加一个图片字段,用来存储产品的图片数据。定义方式如下: ```python class Product(models.Model): _name = 'product.product' _description = 'Product' name = fields.Char(required=True) image = fields.Binary(string="Image") ``` 当我们上传一个图片时,Odoo 会将图片的二进制数据存储到这个字段中。我们可以在后台管理系统中查看和编辑这个字段的值,并可以在模板中使用这个字段来展示图片。 2. 前端文件存储 Odoo 的前端文件存储主要是通过附件(attachment)来实现的。附件可以是任何类型的文件,例如文档、图片、音频等。在 Odoo 中,我们可以在任何一个模型中添加附件字段(attachment field),用来存储附件数据。例如,我们可以在客户模型中添加一个附件字段,用来存储客户的合同文件数据。定义方式如下: ```python class ResPartner(models.Model): _name = 'res.partner' _description = 'Partner' name = fields.Char(required=True) contract = fields.Many2many('ir.attachment', string="Contract") ``` 当我们上传一个附件时,Odoo 会将附件的数据存储到 ir.attachment 表中,并将附件与当前模型记录关联起来。我们可以在后台管理系统中查看和编辑这些附件,并可以在模板中使用这些附件来提供下载链接。 3. 文件下载 Odoo 提供了多种方式来进行文件下载。在后台管理系统中,我们可以直接点击图片或附件字段来下载对应的文件。在模板中,我们可以使用 Odoo 的文件下载链接来提供下载功能。例如,我们可以在客户列表中展示客户的合同文件,并提供下载链接,代码如下: ```xml <tree string="Partners"> <field name="name"/> <field name="contract" widget="many2many_download"/> </tree> ``` 这里使用了 many2many_download widget 来展示客户的合同文件,并提供下载链接。 以上就是 Odoo 后台与前端文件(附件)的存储与下载的浅谈。Odoo 提供了灵活的文件存储和下载方式,可以满足企业级应用的需求。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

趁你还年轻233

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值