-
Notifications
You must be signed in to change notification settings - Fork 62
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
5 changed files
with
131 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
[ | ||
"index.md" | ||
] |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,99 @@ | ||
--- | ||
titleSuffix: 从微前端困境到 ESM 创新:Gez 框架的演进之路 | ||
description: 深入探讨 Gez 框架从传统微前端架构的困境到基于 ESM 的创新突破,分享框架在性能优化、依赖管理和构建工具选型等方面的技术实践经验。 | ||
head: | ||
- - meta | ||
- property: keywords | ||
content: Gez, 微前端框架, ESM, Import Maps, Rspack, 模块联邦, 依赖管理, 性能优化, 技术演进, 服务端渲染 | ||
sidebar: false | ||
--- | ||
|
||
# 从组件共享到原生模块化:Gez 微前端框架的演进之路 | ||
|
||
## 项目背景 | ||
|
||
在过去的几年里,微前端架构一直在寻找一条正确的道路。然而,我们看到的是各种复杂的技术方案,它们用层层包装和人工隔离来模拟一个理想的微前端世界。这些方案带来了沉重的性能负担,让简单的开发变得复杂,让标准的流程变得晦涩。 | ||
|
||
### 传统方案的局限性 | ||
|
||
在实践微前端架构的过程中,我们深刻体会到传统方案的诸多限制: | ||
|
||
- **性能损耗**:运行时注入依赖、JS 沙箱代理,每一次操作都在消耗宝贵的性能 | ||
- **脆弱的隔离**:人工打造的沙箱环境,始终无法企及浏览器原生的隔离能力 | ||
- **构建复杂性**:为了处理依赖关系,不得不魔改构建工具,让简单的项目变得难以维护 | ||
- **定制化规则**:特殊的部署策略、运行时处理,让每一步都偏离了现代开发的标准流程 | ||
- **生态限制**:框架耦合、定制API,让技术选型被迫绑定在特定的生态中 | ||
|
||
这些问题在我们 2019 年的一个企业级项目中表现得尤为突出。当时,一个大型产品被拆分为十余个独立的业务子系统,这些子系统需要共享一套基础组件和业务组件。最初采用的基于 npm 包的组件共享方案,在实践中暴露出了严重的维护效率问题:当共享组件发生更新时,所有依赖该组件的子系统都需要经历完整的构建和部署流程。 | ||
|
||
## 技术演进 | ||
|
||
### v1.0:探索远程组件 | ||
|
||
为解决组件共享的效率问题,Gez v1.0 引入了基于 HTTP 协议的 RemoteView 组件机制。这一方案通过运行时动态请求的方式实现了服务间的代码按需组装,成功解决了构建依赖链过长的问题。然而,由于缺乏标准化的运行时通信机制,服务间的状态同步和事件传递仍然存在效率瓶颈。 | ||
|
||
### v2.0:模块联邦尝试 | ||
|
||
在 v2.0 版本中,我们采用了 [Webpack 5.0](https://webpack.js.org/) 的[模块联邦(Module Federation)](https://webpack.js.org/concepts/module-federation/)技术。这一技术通过统一的模块加载机制和运行时容器,显著提升了服务间的协同效率。但在大规模实践中,模块联邦的封闭式实现机制带来了新的挑战:难以实现精确的依赖版本管理,特别是在统一多个服务的共享依赖时,经常遇到版本冲突和运行时异常。 | ||
|
||
## 拥抱 ESM 新时代 | ||
|
||
在规划 v3.0 版本时,我们深入观察了前端生态的发展趋势,发现浏览器原生能力的进步为微前端架构带来了新的可能: | ||
|
||
### 标准化的模块系统 | ||
|
||
随着主流浏览器对 [ES Modules](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules) 的全面支持,以及 [Import Maps](https://github.com/WICG/import-maps) 规范的成熟,前端开发迎来了真正的模块化时代。根据 [Can I Use](https://caniuse.com/?search=importmap) 的统计数据,目前主流浏览器(Chrome >= 89、Edge >= 89、Firefox >= 108、Safari >= 16.4)对 ESM 的原生支持率已达到 93.5%,这为我们提供了以下优势: | ||
|
||
- **依赖管理标准化**:Import Maps 提供了在浏览器层面解析模块依赖的能力,无需复杂的运行时注入 | ||
- **资源加载优化**:浏览器原生的模块缓存机制,显著提升了资源加载效率 | ||
- **构建流程简化**:基于 ESM 的开发模式,使得开发环境和生产环境的构建流程更加一致 | ||
|
||
同时,通过兼容模式的支持(Chrome >= 87、Edge >= 88、Firefox >= 78、Safari >= 14),我们可以将浏览器覆盖率进一步提升至 96.81%,这让我们能够在保持高性能的同时,不牺牲对旧版浏览器的支持。 | ||
|
||
### 性能与隔离的突破 | ||
|
||
原生模块系统带来的不仅是标准化,更重要的是性能和隔离性的质的提升: | ||
|
||
- **零运行时开销**:告别了传统微前端方案中的 JavaScript 沙箱代理和运行时注入 | ||
- **可靠的隔离机制**:ESM 严格的模块作用域天然提供了最可靠的隔离能力 | ||
- **精确的依赖管理**:静态导入分析让依赖关系更加清晰,版本控制更加精确 | ||
|
||
### 构建工具的选择 | ||
|
||
在技术方案的落地过程中,构建工具的选择是一个关键决策点。经过近一年的技术调研和实践,我们的选择经历了以下演进: | ||
|
||
1. **Vite 探索** | ||
- 优势:基于 ESM 的开发服务器,提供极致的开发体验 | ||
- 挑战:开发环境和生产环境的构建差异,带来了一定的不确定性 | ||
|
||
2. **[Rspack](https://www.rspack.dev/) 确立** | ||
- 性能优势:基于 [Rust](https://www.rust-lang.org/) 的高性能编译,显著提升了构建速度 | ||
- 生态支持:与 Webpack 生态的高度兼容性,降低了迁移成本 | ||
- ESM 支持:通过 Rslib 项目的实践,验证了其在 ESM 构建方面的可靠性 | ||
|
||
这一决策让我们在保持开发体验的同时,获得了更稳定的生产环境支持。基于 ESM 和 Rspack 的组合,我们最终构建了一个高性能、低侵入性的微前端解决方案。 | ||
|
||
|
||
## 未来展望 | ||
|
||
在未来的发展规划中,Gez 框架将重点关注以下三个方向: | ||
|
||
### Import Maps 深度优化 | ||
|
||
- **动态依赖管理**:实现运行时依赖版本的智能调度,解决多应用间的依赖冲突 | ||
- **预加载策略**:基于路由分析的智能预加载,提升资源加载效率 | ||
- **构建优化**:自动生成最优的 Import Maps 配置,减少开发者的手动配置成本 | ||
|
||
### 框架无关的路由方案 | ||
|
||
- **统一路由抽象**:设计框架无关的路由接口,支持 Vue、React 等主流框架 | ||
- **微应用路由**:实现应用间的路由联动,保持 URL 与应用状态的一致性 | ||
- **路由中间件**:提供可扩展的中间件机制,支持权限控制、页面转场等功能 | ||
|
||
### 跨框架通信最佳实践 | ||
|
||
- **示例应用**:提供完整的跨框架通信示例,涵盖 Vue、React、Preact 等主流框架 | ||
- **状态同步**:基于 ESM 实现的轻量级状态共享方案 | ||
- **事件总线**:标准化的事件通信机制,支持应用间的解耦通信 | ||
|
||
通过这些优化和扩展,我们期望让 Gez 成为一个更加完善、易用的微前端解决方案,为开发者提供更好的开发体验和更高的开发效率。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,18 @@ | ||
--- | ||
titleSuffix: Gez 团队博客 | ||
description: Gez 团队的技术博客,分享框架开发经验、最佳实践和技术创新。 | ||
head: | ||
- - meta | ||
- property: keywords | ||
content: Gez, 团队博客, 技术分享, 最佳实践, 开发经验 | ||
sidebar: false | ||
--- | ||
|
||
# 团队博客 | ||
|
||
欢迎来到 Gez 团队的技术博客!在这里,我们将分享框架开发过程中的经验、技术创新和最佳实践。 | ||
|
||
## 最新文章 | ||
|
||
- 2025-02-25 [从组件共享到原生模块化:Gez 微前端框架的演进之路](./birth-of-gez.md) | ||
> 探索 Gez 框架从传统组件共享到基于 ESM 的原生模块化演进历程,分享在性能优化、依赖管理和构建工具选型等方面的技术实践经验。 |