最近实践了微前端，写了个 blog 总结下

[MorningStar0]

示例项目的微前端迁移(仓库的 micro-front 分支)已完成：

• 目录结构重构
• 公共 module 引用抽离
• 公共 module 统一构建
• 公共 deps 抽离
• 公共依赖版本控制

blog 地址

[Azuer]

微前端是个什么概念？

[hucw21750]

我们公司产品后台管理应用已成为巨石应用，一直想搞微前端分解下业务，奈何人力时间都不足，都是在脑海中实践。

[musi]

“你可能并不需要微前端”

[musi]

@musi #3 仔细看了一下就是 monorepo ，不是前端吹的微前端

[lrwlf]

你说的这几点不是大仓吗，跟微前端有什么关系么

[horizon]

我也不懂什么是微前端。。

[MorningStar0]

@lrwlf
@musi
这里就是第一步拆分依赖和公共包，后续计划会完成组件的独立开发，让组件可以通过网络在运行时加载

[musi]

@MorningStar0 #7 你这微前端的部分都还没开始怎么就开始吹微前端了，还有现在微前端已经玩烂了，阿里又开始说“你可能并不需要微前端”了

[MorningStar0]

@musi 呃我理解，微前端也包含我提到的这部分吧，而且我就是记录下自己实践的部分，blog 中提到的后续计划，已经在开发中了。
通过网络动态引用的部分已经完成了，只是其他计划还没有完成，我觉得不适合单独写一个专题。
动态引用的代码，在仓库中的 dynamic-import module 中

[lrwlf]

@MorningStar0 似乎不是想要像传统“微前端”那样拆分子应用，而是更细化到组件和 SDK 。有点像“模块联邦”，可以参考 https://tnfe.github.io/hel/

[musi]

@MorningStar0 #9 现在市面上的为前端框架重点除了是远端加载更重要的是代码隔离，让远端的代码运行在一个沙箱环境之中，这个基本上是工作量的大头，远端加载的话其实是比较简单的

[MorningStar0]

@MorningStar0 #9 至于微前端玩烂了，还有 ali 的技术观点，其实不太影响我。总的来说 我的需求对于微前端时刚需，这点是指我在 blog 中提到的
“对于不同用户，同一个包需要在运行时 提供不同的版本”。

[yaphets666]

@musi 远端代码运行在沙箱是什么意思？前端代码都是运行在浏览器啊

[musi]

@yaphets666 #13 就是在浏览器里面构建了一个 js 沙箱，去运行不受信的代码，或者说不能对主应用造成干扰

[MorningStar0]

@musi 沙箱还是需要的，我这里目前的方案是，将通过 new Function 加载的远程库，把它的 context 绑定到一个 object 下，这个 object 提供了一些允许调用全局变量。

[MorningStar0]

@lrwlf 可能我这个 blog 中给出的例子确实更像模块联邦😂

[yikyo]

@yaphets666 微应用级别的隔离，防止几个微应用间冲突。沙箱的话，核心代码只有几行，你可以看一下 神光的编辑秘籍 近期那篇微前端方案那篇文章

[zhaol]

微前端最大的问题就是信息传递，贼麻烦，真的。应用一但多起来，共享状态的管理真的很麻烦，debug 的时候也很头疼。主应用和微应用以及不同微应用之间的交互也麻烦，能别微前端就别微前端。不过学学技术可以，业务中尽量少用

[MorningStar0]

@zhaol 确实比较麻烦，我的解决方案是将带有 context 的功能，作为单独的 module 打包，然后在构建的时候，保持这个 context 的唯一实例。

[alexsunxl]

你这个理解的微前端是不是有点问题。你这属于是组件优化层面。
不是说 monorepo 就是微前端。
微前端并不是解决 项目大的问题啊。
我理解的微前端和微服务的核心关键词都是一个： 技术栈无关。

你得把 vue2 ，vue3 ，angular ，react ，原生 js 通过路由层能揉在一起的才叫微前端。
微服务也一样的。每个团队能选自己的技术栈（ go ，java,python...)和框架，最后只要按规范接入平台作为一个完成服务就行。