【发布时间】：2019-10-03 12:40:32
【问题描述】：
据我所知，使用微前端时有两种流行的情况 -
1) 带有组件的单页（每个都有自己的服务） 2）从仪表板/导航栏访问多个页面（每个部分都有自己的服务）
我已经研究了一段时间，据我所知，案例 1 在使用 Angular 自定义元素时非常简单。
问题是我需要解决案例 2。 按照设计，我有一个仪表板（页面侧面的导航栏），其中包含不同组件入口点（报告、用户等）的路线列表。
我希望这部分成为容器，并且容器导航栏上的每条路由都通向一个独立的微前端，该微前端可以独立存在并作为容器的一部分。 因此，当我构建完整站点时，我将拥有例如 reportService、userService 等......以及主/容器服务。
我无法确定实现该目标的最佳方法是什么，我看过各种各样的文章，但我仍然看不到一条清晰的道路（准备好产品等...）
是否有任何流行且可用于生产的方法？
编辑：这个想法是例如 - 能够让两个团队各自在网站的单独部分（单独的上下文）上工作，而不会相互影响。两者都有站点的独立部分，并且在部署时可以将更改添加到主包含站点。这两个子站点之间的连接很少（如果有的话），它们可以单独运行，也可以在容器内运行。
我添加了一篇文章的链接，该文章解释了我的问题等等，而且做得比我做得更好 https://martinfowler.com/articles/micro-frontends.html
【问题讨论】：
-
我不想听起来刻薄，但您似乎在使用您并不真正了解的单词，这会导致句子非常模糊......在 Angular 中，每页SPA 有自己的组件，它们通常是路由的，服务只是包含所有业务逻辑的类。我不知道“使用微前端时的两种流行情况”，将微方面扩展到前端可能不是一个好主意（因为 Angular 已经在内部这样做了）。
-
我明白，我确实对项目本身进行了分离..分离的模块和其他标准方法用于分离 Angular 项目中的组件和逻辑。但我正在测试一个将其移出到自己的项目中的选项。在客户端执行此操作也有一些非常好的好处。
-
所以您正在从微服务架构（如 API）迁移到单体架构，而不是相反？
-
我看过您的其他评论（关于答案）：您不必担心 Angular 中的冲突，每个模块都与其兄弟模块分开。正如我所说，与 API 不同，这一切都是在幕后完成的。如果我能给你一个强硬的建议，那就是不要将后端原则应用于项目的前端。他们分开是有原因的，在尝试这样的事情时，你会比结果更头疼。
-
在选择这种方法时，服务器端或客户端确实更复杂。但这似乎是一切都转移到的地方，更小的组件、更小的单元、更多的分离等等......我想在一个新项目上测试它。因为无论 Angular 框架处理得多么好，我都看到了拥有客户端单体应用的许多负面影响。