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

[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 的管理, 冲突, 发布这些就够你喝一壶的了

[hamsterbase]

组织架构决定软件架构。 微应用适合大公司，各个事业线一起开发同一个产品。 相互独立发布，不干扰。

[Hilong]

微应用还有一个用途, 同一个子应用可以被多个主应用引入, 可以做到灵活拼接业务.

[aikilan]

@throns 确实，不同技术栈杂糅在一起，十分令人不适。

[aikilan]

@libook
@hamsterbase
绝大部分公司的业务发展决定了技术架构的走向这点我十分认同，一家能纯粹靠技术推动业务的企业九牛一毛吧，有时候也会迷茫，绝大多数业务场景下，其实很入门的解决方案或者说技术栈就完全能够满足，但是对于一个技术人员来说，是不是需要主动的去做些什么，或者说“前瞻性”的去推动一些东西，其实说多了也是私心作祟。

[libook]

@aikilan 企业的目标是盈利，所以实际上都是需求驱动技术，反过来不符合企业发展的客观规律，除非是在研究机构，或是土豪公司愿意出钱养创新。

像微前端这种也是企业业务需求、经营成本需求、管理需求所催生出来的技术，是现阶段满足特定需求的最佳方案而已。

我个人认为，作为技术人员，首先要了解业务，然后才能根据业务需求精准得进行技术选型和技术设计。其次是做好技术雷达，了解新技术和行业案例，了解各项技术可以如何满足业务需求或者解决业务问题，从而在合适的时机可以被引入项目并被有效地利用。

在企业中工作，就要用企业一样的思维来思考。

[dudubaba]

那是你没做过 saas 化开发，特别是面向定制需求的。