突然意识到，前端微应用也许是个伪需求

[aikilan]

最近基于 single-spa 拆分了日渐庞杂的一个前端工程，工程本身基于 vite 开发，子应用也全部使用 vite ，这中间大小坑多少也踩的差不多了，子应用的 hot reload/unmount/自动切换子应用的环境 /根据权限渲染子应用 /数据、权限、方法共享巴拉巴拉......

搞完以后，索然无味，突然意识到，这个改造的过程中，似乎终极目标就是让子应用的使用体验就像是写在同一个工程内一样，问题来了，既然终极目标就是写在同一个工程内，那么为什么一开始我要拆分呢？难道仅仅是为了一个概念上的“微前端”？？？

前端子应用的本质是为了追求独立部署（也许吧），但是在实际业务中，子应用很可能是一个看似独立实则业务与父应用高度耦合的模块，这就不可避免子应用调用父应用诸多业务实现，你很少有独立存在的必要（起码在我接触的业务中是这样的），这就意味着一旦子应用脱离了父应用的环境，你就需要为这些原本属于父应用的业务能力打补丁，这就显得很冗余。

如果父子应用都写在一个工程内，通过修改构建配置，实现独立打包 /部署，那么不但可以避免最开始那些需要踩的坑，还能轻松共享不同应用间的业务 /组件能力，所以诸如 single-spa 的出现，解决的是哪些真实业务场景需求呢？我很迷惑。当然了，搞技术的嘛，贵在折腾，于我个人而言，我还是有收获的。

最后，有折腾的机会我还是会去折腾的。

[musi]

single-spa 是让不同技术栈可以跑在一个项目里，比如说在 vue 里跑 react 。
如果你只是想做代码层级上的拆分，monorepo 就够了

[aikilan]

@musi 是，这个确实属于需求点

[wu67]

个人觉得, 是为了把现有的旧项目和新开的项目糅合在一起上线, 然后在后续的迭代过程中, 逐步重写替换旧应用.

如果是新开项目线这么折腾, 那我觉得真是没必要...

[aikilan]

@wu67 业务的规划十分的庞大，给我一种错觉，"这玩意儿得特么上微应用了吧"，实际业务来了以后，零零碎碎，笑死

[dsggnbsp]

这么一说 还真是 也许是为了找活做（ kpi ） 实际体验其实不咋地

[can2421]

我们这里之前也是把一个 vue2 的老项目拆成微应用了, 拆分出来的升级成 vue3, 而且把以前那些烂代码也重构了一下, 之前发版构建打包的时间超长, 现在爽多了, 不过坑也确实挺多的

[aboat365]

微前端是前端的微服务架构，这个架构的出现如同后端的微服务架构一样，都是为了解决巨大的单体服务带来的问题。
微前端并不是为了每个子应用都要独立出去提供业务支持，其目标之一是各个子应用独立运行，并互相调用方便可靠。

[pjee]

以前有人给我说过一个原因，我觉得非常有道理：微服务、微应用、微前端的真正目的为了避免和 sb 一起写代码

[aikilan]

@can2421 确实，从开发角度来说，构建速度和开发体验上确实有所提升，但是这个通过构建方式改造也可以实现，不同应用划分不同入口，组件 /状态 /方法都在同一个工程下，构建和发包则分开执行。

[aikilan]

@pjee 哎哟卧槽

[throns]

为了微应用而微应用着实没有必要，在一个应用程序中使用多个前端框架本来就是反模式的。但是对于老系统，或者因为历史原因，合并不同技术栈的项目采用 single-spa 这个妥协的方案个人觉得无可厚非。
只是为了把一个庞大的单体应用拆分完全没必要用 single-spa ，拆分的目的是什么？一定要明确这一点。个人觉得最主要的收益是应用可以独立部署，减少迭代的冲突，大型的后台运营系统往往是把很多功能组合起来的，一个单体应用很容易会遇到多个需求同时修改这个应用的代码，但是这些需求又不会互相影响，不会改到同一个地方的代码。当遇到这种情况越来越多，需要不断去合并代码，商量上线日期，微前端是有必要的。
个人觉得最佳的实践是在同一个前端团队里，承接有不同的业务，以业务来进行划分，在一个大型的后台系统里汇总所有的功能，团队内的技术栈统一。

[gkinxin]

使用技术也得看情况，可以看看阿里云的控制台，这种应用场景是非常合适的。

[akvo]

满足以下几点，你才确实可能需要微前端

1. 系统本身是需要集成和被集成的 一般有两种情况：
a. 旧的系统不能下，新的需求还在来。
没有一家商业公司会同意工程师以单纯的技术升级的理由，直接下线一个有着一定用户的存量系统的。而你大概又不能简单通过 iframe 这种「靠谱的」手段完成新功能的接入，因为产品说需要「弹个框弹到中间」
b. 你的系统需要有一套支持动态插拔的机制。
这个机制可以是一套精心设计的插件体系，但一旦出现接入应用或被接入应用年代够久远、改造成本过高的场景，可能后面还是会过渡到各种微前端的玩法。
2. 系统中的部件具备足够清晰的服务边界
通过微前端手段划分服务边界，将复杂度隔离在不同的系统单元中，从而避免因熵增速度不一致带来的代码腐化的传染，以及研发节奏差异带来的工程协同上的问题。

-------
摘自 https://zhuanlan.zhihu.com/p/391248835

其实个人觉得如果业务方面分界点很清晰的时候确实是有用的，当然，楼上的说法其实也蛮有道理 :_)

[janus77]

这不跟后端上微服务一样么，一开始觉得要追潮流，能上都上，结果过了两年发现根本没必要，还是单体服务更舒服

[throns]

@akvo 很赞同。个人觉得简单地把多个技术栈的页面组合在一起就是一个不可接受的行为，就像勒拿九头蛇，看着像一个整体，但每个部分都很割裂。

[coolcoffee]

我觉得还得看团队规模来决定要不要上微服务 /前端。

当团队人少的时候，这个时候团队迭代目标基本上一致，拆分微服务会增加基础组件维护的成本。

当团队人多的时候，特别是涉及到多部门共同维护一个大后台，每个团队的迭代计划都不相同，再在同一个仓库维护就会出现很多的协作问题。 这个时候合并在一起开发的效率损耗就会大于拆分微服务 /前端的损耗，所以适合选择效率损耗更小的微服务 /前端。

[mingoing428]

所谓的微前端都能用多页构建和多包仓库代替。
微前端拆分更多的是管理问题，而不是技术问题

[colorcat]

这东西就是 1%的需求

[libook]

架构思想、框架、工具都是为需求服务的，有需求就用，没需求没必要硬用。

微前端我听过阿里云的分享，阿里云的云控制台上有超多功能，超多团队分别负责，每种功能可能采用不同的框架来做的，而且也要兼容很多年不动的旧代码，如果不做微前端框架就会导致要么一直用统一的旧技术，要么把包括不需要改动的功能一起用新技术重构。

如果你就做一个一个团队维护的中型项目，可以统一框架和库的版本，也可以使用统一的项目结构，确实没必要用微前端。

[grewer]

同一个仓库, 光是 git 的管理, 冲突, 发布这些就够你喝一壶的了