草庐IT

SREWorks前端低代码组件生态演进:monorepo架构重构和远程组件加载实践

阿里云大数据AI技术 2023-03-28 原文
作者:王威(地谦)

文章结构

  • 项目背景
  • 演进分析
  • monorepo架构演进
  • Webpack与Rollup
  • 如何平滑迁移
  • 构建优化
  • 组件的可扩展与可插拔
  • 演进总结
  • 版本动态

项目背景

SREWorks是一个面向企业级复杂业务的开源云原生数智运维平台,是大数据SRE团队多年工程实践的锤炼及沉淀。前端统一托管工程(frontend)作为平台的重要一环,提供了一套serverless体验的配置化前端低代码技术方案:低代码、配置化是前端低代码方案的基础特性。

frontend工程采用React+antd为主的技术框架,设计了一套组件映射、编排、解析、渲染的工程体系:以antd组件为自由编辑粒度,用户在前端设计器通过可视化交互或者json编辑的方式,依据运维工作的实际使用场景,对组件进行属性配置/组件嵌套拼装;同时根据使用景目标需求对页面组件进行布局的编排、数据源的绑定以及在合适点位插入Dynamic Logic,完成页面节点的设计工作,形成节点模型nodeModel,经模板解析引擎进行解析渲染。

我们开源这套前端工程的愿景是:沉淀更多的使用场景,整合更多的用户需求,与社区一起共建一个丰富的前端运维组件生态。在过去的半年中,为了让前端组件生态更好地演进,frontend 针对 “可扩展、方便插拔”这两个关键点进行架构升级:

  1. 架构层面进行了monorepo模式重构;
  2. 前端组件支持远程动态加载;
在文本中,我们对整个迭代过程中陆陆续续碰到过一些问题,以及技术方案的选择与思考做一个阶段性的归纳和总结。

演进分析

关注我们开源动态的同学应该知道,我们初版开源的frontend代码量近10万之多,在没有可靠详实文档的帮助之下,想要快速理清楚整套工程的设计理念,结构机理进而能参与贡献还是有一定难度的。同时工程内部细分来看,设计器,模型层,组件层各自又有相差很大的更新频率,在开发时一个小小的改动都需要整个工程进行构建。

另外一方面,frontend来源于公司内部工程实践的版本,两者虽然同源,但是由于公司内部和开源场景都在快速功能演进,最初设计的公共框架层和组件层共享机制已经有些举步维艰,这也为后续这次演进迭代埋下了伏笔。结合我们打造开源生态“可扩展、方便插拔”两大目标,综合来看需要解决以下问题:

  • 基座层面支持runtime远程组件的加载,解决用户的多样化的场景与诉求
  • 结构上对大而全的工程进行细粒度拆分
  • 提取framework框架层和widget组件层并能够单独构建
  • share-tools工具可共享
  • 内部业务代码剥离
  • 在适配内部业务运转的前提下升级各依赖版本,便于新技术引入与演进
  • 构建工具的升级与配置调优,有效提升构建效率降低构建体积
针对以上待解决的问题,对演进方案进行了技术调研,也参考和采纳了社区同学的建议,我们决定采取下面两个方案来解决上文提到的问题:

  1. 架构层面,采用monorepo模式进行重构提取出framework框架层、widget组件层、shared-tools等几个子依赖包,以webpack5(主应用包)+rollup(子依赖包)作为构建工具进行过调优构建;
  2. 针对无法进入代码库的组件,提供远程组件脚手架,支持将远程组件打包umd格式并以动态script标签形式进行动态引入和移除,做到runtime加载扩展;
下面我们来详细分享下这两项方案的实施:

Monorepo架构演进

Monorepo即单仓(repository)多包(package),大型前端工程项目采用这种模式进行开发管理,能带来诸多的开发和管理便利:

  • 更加清晰的模块结构和依赖关系
  • 更细粒度的独立构建单元便于协作开发和不同更新频率的子包单独发版
  • 更加高效的代码复用等
在v1.4版本中采用lerna + yarn workspace 的技术方案进行了Monorepo的架构实践:将原工程拆分为@sreworks/app主包应用,和@sreworks/components、@sreworks/widgets、@sreworks/framework、@sreworks/shared-utils四个npm子依赖包。目录结构变动如下图所示:

通过lerna+yarnworkspace的方案,将各子包配置进入workspace空间,workspace空间的各子依赖包的更新,会实时同步到主应用包的node_module,无需发布npm,且能选择针对特定子包单独发布npm版本或者各个包同步发布新的版本,可以更小粒度的更新主应用依赖,便捷高效。

Webpack与Rollup

在设计好子包的拆分之后,就开始着手进行文件结构的改造、组件引入挂载方式的变更、远程组件加载的处理优化,主题式样的迁移等等问题(由于篇幅有限,本文仅对大的通用环节进行介绍,对处理细节感兴趣或者想讨论沟通的同学可以加入文末的交流群)。

在处理完工程结构代码后,我们开始着手工程的构建:构建工具的选择,关于构建工具,webpack,gulp,rollup以及后来的vite,综合我们实际的情况,最后选定了Webpack和Rollup作为备选方案:Webpack和Rollup本质都是对非ES5代码的转义与打包,一个功能强大的compiler函数,通过配置入口读取目标文件,然后输出转义文件;要完成整个工程的打包,还需要babel-loader,React和Vue等loader的处理和一系列plugin的适时挂载处理才能完成对诸如图片,css文件、JSX及Vue template等类型文件的处理,及js挂载html的工作。

Webpack与Rollup的特点:

根据以上特点对比以及参考业内优秀开源项目实践,frontend选择了主包应用使用Webpack5作为构建工具,Rollup作为子包应用构建工具的方案,主包应用HMR对于日常开发而言是刚需,因此选择Webapck;对子包依赖而言,更便捷的配置和更小的输出才是更佳的选择。

如何平滑迁移

整个这么大的工程体量,在没有完全进行代码层面准确无误的拆解并构建的情况下,是跑不起来的,一个很小的错误都会造成整个项目抛错。且二方包使用了sourcemap也是没有用的,经过了主包构建,很难排查出哪里除了问题,于是就又要推倒重来……在开始的实时过程中,耗费了很多的时间,叠加每个子包的修改排查,主应用包的构建等验证周期很长,探索性改造的难点就在于此。

那么能更小粒度的验证和迁移吗?远程组件的加载给了启发思路。尝试性将组件包@SREWorks/widgets打包成esm格式并在原来大而全的工程中直接修改node_modlues引入依赖包打包文件, 和相应加载机制,在能运行起来的工程上去验证各子依赖包,配合sourcemap, 问题排查瞬间提速。就这样,又依次进行@SREWorks/framework等其他包的验证,蒙眼构建排查问题得解。

式样问题比较头疼,在此采用的方案是通用式样在主包保留,子包由于式样重置覆盖的场景较少,采用了css-module的方式进行隔离构建。

构建优化

经过各子依赖包在原有工程上进行平滑验证,来到主应用包的构建环节,构建体积竟然达到了惊人的5.5M,还是gzip压缩后的体积:

通过分析这张图,该版本构建存在以下问题:

  • 同名依赖多次出现,各子依赖包存在重复的依赖
  • 部分依赖包构建体积偏大,如BizCharts
针对以上存在的问题对@sreworks/app整体进行三个维度的优化处理:

第一,通过统一子包依赖排查合并依赖版本,优化至2.8M

const namespace = {
appRoot: path.resolve('src'),
appAssets: path.resolve('src/assets'),
// 减少子依赖包内部重复依赖
'@ant-design': path.resolve(process.cwd(), 'node_modules', '@ant-design'),
'js-yaml': path.resolve(process.cwd(), 'node_modules', 'js-yaml'),
'ace-builds': path.resolve(process.cwd(), 'node_modules', 'ace-builds'),
'brace': path.resolve(process.cwd(), 'node_modules', 'brace'),
'lodash': path.resolve(process.cwd(), 'node_modules', 'lodash')
}
...
resolve: {
alias: paths.namespace,
modules: ['node_modules'],
extensions: ['.json', '.js', '.jsx', '.less', 'scss'],
},

第二,抽离部分大依赖包到cdn,如下在externals配置项进行剥离;将体积优化至1.6M。但考虑到某些专有云使用场景,无法使用外部cdn。于是采用自定义构建脚本,从node_modules中迁移目标依赖到输出文件夹并加载至html的方案,降低参与构建的大依赖包数量,同时保证专有云环境对其正常的使用。

externals: {
// 剥离部分依赖,不参与打包
'react': 'React',
'react-dom': 'ReactDOM',
"antd":"antd",
...
},

第三,调整关键组件路径和1.48M, 减少体积70%,构建时间由V1.3版本的74秒,优化至23秒,提升68%。

组件的可扩展与可插拔

虽然frontend已内置运维场景常用的基础组件,图表组件,landing组件,布局组件等五十余个组件。根据开源之后用户的使用反馈来看,用户仍然有着定制化,可扩展的共性诉求:总的来讲大致分为两大类:

  1. 前端框架也是React,有自己定制化的使用场景,内置组件不能满足当前需求,需要扩展
  2. 前端技术栈是Vue,历史组件积淀比较多,全部进行React重构成本太大
针对问题一,frontend本来就有提供JSXRender,支持用户以JSX进行简单的静态渲染类的组件自定义扩展,但不支持属性配置以及数据源及dynamic业务逻辑处理等高级特性。前端插件化,很容易想到npm包的引入,但是这也只能在工程代码开发的场景下才适配,要runtime使用和移除,就要另寻方案。再进一步深入追溯,前端开发从jQuery时代发展到当今的Agular,React,Vue三驾马车以及各种工程化构建工具的参与,但本质其实并没有发变化,依然是以html中以script标签挂载js代码进行渲染加载的。因此自然想到以script标签的形式加载我们的远程组件,不过这里要做到动态、批量加载、可移除,即:将远程组件打包umd格式并发布到云端,并获取相应准确路径,以动态script标签的形式引入:

(function (){
let script = document.createElement('script')
script.type = 'text/javascript'
script.src = url // 目标组件url
document.getElementById('targetDomId').appendChild(script)
})()
script.addEventListener('load',callback,false) // 嵌入逻辑

如果要批量加载多个的话,即:

const loadRemoteComp = async () => {
let remoteCompList = ["url_a","url_b","url_c",...];
try {
remoteComList.forEach(item => {
pros.push(Promise.resolve(loadSingleComp());
})
window['REMOTE_COMP_LIST'] = await Promise.all(pros);
} catch (error) {
console.log(error);
}
}
loadRemoteComp()

当然这里还涉及到浏览器终端适配,容错等细节。在此frontend采用比较成熟的systemjs包进行组件的加载,对以上细节都有做妥善处理,合理借力,省时高效。

针对问题二, 技术栈不同,即异构组件的加载。目前来说frontend暂且只针对Vue组件做了异构兼容渲染,在React中使用Vue组件。一开始想到的是使用转换工具,将vue组件手动转换为React组件,之后再粘贴构建,但这种方式有个很大的缺陷:不同版本api差异较大,手动转码一般需要对转换过后的代码进行人工二次排查调整,需要开发人员对于两种框架的新老版本属性熟悉了解,对于不符合的代码或已更新的hooks等进行二次确认,无形中提高了使用门槛。

受到Docker容器的启发,思考React和Vue虽然属于不同的技术栈体系,但区别于Java和Golang的差异,Vue和React在本质上都是原生js对象的封装,所以理论上讲是可以在React中进行容器化渲染Vue组件的:即本质是绑定挂载Vue对象的操作:

createVueInstance (targetElement, reactThisBinding) {
const { component, on, ...props } = reactThisBinding.props
reactThisBinding.vueInstance = new Vue({
el: targetElement,
data: props,
...config.vueInstanceOptions,
render (createElement) {
return createElement(
VUE_COMPONENT_NAME,
{
props: this.$data,
on,
},
[wrapReactChildren(createElement, this.children)]
)
},
components: {
[VUE_COMPONENT_NAME]: component,
'vuera-internal-react-wrapper': ReactWrapper,
},
})
}

通过frontend远程组件脚手架@sreworks/widget-cli,对React组件和Vue组件进行打包并发布到cdn,然后在物料开发处,进行编辑即可便捷进行远程组件runtime加载和移除,解决了问题一和问题二,达成了“扩展性”和“可插拔”的目标。

演进总结

到这里,基本解决了开篇列举的一系列问题,为构建前端运维组件生态铺设好了共建路径,可以做到:

  • 从@sreworks/widgets包开发,JSXRender自定义组件,使用@sreworks/widget-cli开发远程组件三个维度扩展组件应用丰富度
  • 更加清晰的结构依赖关系,降低学习和贡献参与这套低代码工程的门槛
  • 以更小粒度的更新单元,更短的构建时间,便捷日常协作开发
  • 子包拆分后,为后续小规模分步引入TS提供了条件

版本动态

我们会根据工作项目节奏,持续对功能进行完善优化和升级,当前主要是前端低代码功能的输出,后续API低代码编辑编排已纳入版本规划,以覆盖全链路低代码使用,大家有比较好的建议欢迎多提issue,同时也欢迎更多的开发者能够参与到我们的生态建设中来(@小助手,也可以直接前端@地谦)

SREWorks开源地址:

​https://github.com/alibaba/sreworks/paas/frontend​

有关SREWorks前端低代码组件生态演进:monorepo架构重构和远程组件加载实践的更多相关文章

  1. ruby-on-rails - 使用 Ruby on Rails 进行自动化测试 - 最佳实践 - 2

    很好奇,就使用ruby​​onrails自动化单元测试而言,你们正在做什么?您是否创建了一个脚本来在cron中运行rake作业并将结果邮寄给您?git中的预提交Hook?只是手动调用?我完全理解测试,但想知道在错误发生之前捕获错误的最佳实践是什么。让我们理所当然地认为测试本身是完美无缺的,并且可以正常工作。下一步是什么以确保他们在正确的时间将可能有害的结果传达给您? 最佳答案 不确定您到底想听什么,但是有几个级别的自动代码库控制:在处理某项功能时,您可以使用类似autotest的内容获得关于哪些有效,哪些无效的即时反馈。要确保您的提

  2. ruby - 如何在 buildr 项目中使用 Ruby 代码? - 2

    如何在buildr项目中使用Ruby?我在很多不同的项目中使用过Ruby、JRuby、Java和Clojure。我目前正在使用我的标准Ruby开发一个模拟应用程序,我想尝试使用Clojure后端(我确实喜欢功能代码)以及JRubygui和测试套件。我还可以看到在未来的不同项目中使用Scala作为后端。我想我要为我的项目尝试一下buildr(http://buildr.apache.org/),但我注意到buildr似乎没有设置为在项目中使用JRuby代码本身!这看起来有点傻,因为该工具旨在统一通用的JVM语言并且是在ruby中构建的。除了将输出的jar包含在一个独特的、仅限ruby​​

  3. ruby-on-rails - Rails 源代码 : initialize hash in a weird way? - 2

    在rails源中:https://github.com/rails/rails/blob/master/activesupport/lib/active_support/lazy_load_hooks.rb可以看到以下内容@load_hooks=Hash.new{|h,k|h[k]=[]}在IRB中,它只是初始化一个空哈希。和做有什么区别@load_hooks=Hash.new 最佳答案 查看rubydocumentationforHashnew→new_hashclicktotogglesourcenew(obj)→new_has

  4. ruby - 如何在续集中重新加载表模式? - 2

    鉴于我有以下迁移:Sequel.migrationdoupdoalter_table:usersdoadd_column:is_admin,:default=>falseend#SequelrunsaDESCRIBEtablestatement,whenthemodelisloaded.#Atthispoint,itdoesnotknowthatusershaveais_adminflag.#Soitfails.@user=User.find(:email=>"admin@fancy-startup.example")@user.is_admin=true@user.save!ende

  5. ruby - RuntimeError(自动加载常量 Apps 多线程时检测到循环依赖 - 2

    我收到这个错误:RuntimeError(自动加载常量Apps时检测到循环依赖当我使用多线程时。下面是我的代码。为什么会这样?我尝试多线程的原因是因为我正在编写一个HTML抓取应用程序。对Nokogiri::HTML(open())的调用是一个同步阻塞调用,需要1秒才能返回,我有100,000多个页面要访问,所以我试图运行多个线程来解决这个问题。有更好的方法吗?classToolsController0)app.website=array.join(',')putsapp.websiteelseapp.website="NONE"endapp.saveapps=Apps.order("

  6. ruby-on-rails - 浏览 Ruby 源代码 - 2

    我的主要目标是能够完全理解我正在使用的库/gem。我尝试在Github上从头到尾阅读源代码,但这真的很难。我认为更有趣、更温和的踏脚石就是在使用时阅读每个库/gem方法的源代码。例如,我想知道RubyonRails中的redirect_to方法是如何工作的:如何查找redirect_to方法的源代码?我知道在pry中我可以执行类似show-methodmethod的操作,但我如何才能对Rails框架中的方法执行此操作?您对我如何更好地理解Gem及其API有什么建议吗?仅仅阅读源代码似乎真的很难,尤其是对于框架。谢谢! 最佳答案 Ru

  7. ruby - 模块嵌套代码风格偏好 - 2

    我的假设是moduleAmoduleBendend和moduleA::Bend是一样的。我能够从thisblog找到解决方案,thisSOthread和andthisSOthread.为什么以及什么时候应该更喜欢紧凑语法A::B而不是另一个,因为它显然有一个缺点?我有一种直觉,它可能与性能有关,因为在更多命名空间中查找常量需要更多计算。但是我无法通过对普通类进行基准测试来验证这一点。 最佳答案 这两种写作方法经常被混淆。首先要说的是,据我所知,没有可衡量的性能差异。(在下面的书面示例中不断查找)最明显的区别,可能也是最著名的,是你的

  8. ruby - 寻找通过阅读代码确定编程语言的ruby gem? - 2

    几个月前,我读了一篇关于ruby​​gem的博客文章,它可以通过阅读代码本身来确定编程语言。对于我的生活,我不记得博客或gem的名称。谷歌搜索“ruby编程语言猜测”及其变体也无济于事。有人碰巧知道相关gem的名称吗? 最佳答案 是这个吗:http://github.com/chrislo/sourceclassifier/tree/master 关于ruby-寻找通过阅读代码确定编程语言的rubygem?,我们在StackOverflow上找到一个类似的问题:

  9. ruby-on-rails - 使用 config.threadsafe 时从 lib/加载模块/类的正确方法是什么!选项? - 2

    我一直致力于让我们的Rails2.3.8应用程序在JRuby下正确运行。一切正常,直到我启用config.threadsafe!以实现JRuby提供的并发性。这导致lib/中的模块和类不再自动加载。使用config.threadsafe!启用:$rubyscript/runner-eproduction'pSim::Sim200Provisioner'/Users/amchale/.rvm/gems/jruby-1.5.1@web-services/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:105:in`co

  10. ruby - Net::HTTP 获取源代码和状态 - 2

    我目前正在使用以下方法获取页面的源代码:Net::HTTP.get(URI.parse(page.url))我还想获取HTTP状态,而无需发出第二个请求。有没有办法用另一种方法做到这一点?我一直在查看文档,但似乎找不到我要找的东西。 最佳答案 在我看来,除非您需要一些真正的低级访问或控制,否则最好使用Ruby的内置Open::URI模块:require'open-uri'io=open('http://www.example.org/')#=>#body=io.read[0,50]#=>"["200","OK"]io.base_ur

随机推荐