几年前，我在华沙举行的JS波兰会议上首次听说了Microfrontends一词。卢卡·梅扎利拉（Luca Mezzalira）关于这个话题有一个很好的演讲，在看到这个话题之后，我考虑了自己构建此类应用程序。我用React和Vue创建了一些简单的概念证明，我真的很喜欢这个想法。
但是，在我的工作项目中，我从来没有机会构建此类系统。我真的希望在接下来的几个月或几年中，我将能够建立这种架构模式看起来确实很有希望的应用。
一般的想法
“ Micro Frontends”一词在2016年底首次出现在Thoughtworks Technology Radar中。它将微服务的概念扩展到了前端世界。当前的趋势是构建功能丰富且功能强大的浏览器应用程序，即单页应用程序，该应用位于微服务架构之上。随着时间的流逝，通常由单独的团队开发的前端层成长，并且变得更加难以维护。那就是我们所说的前端巨石。让我们看一下有关不同体系结构模式的以下图。
Micro Frontends背后的想法是将网站或Web应用程序视为独立团队拥有的功能的组成。每个团队都有其关心和专门研究的业务或任务的独特领域。一个团队是跨功能性的，并开发了从数据库到用户界面的端到端的功能。让我们看一下有关微注射体系结构的以下图：
所以示例应用程序可能看起来像这样：
来源：https://martinfowler.com/articles/micro-frontends.html
我们已经知道什么是微额定体系结构，让我们看一下使用它的利弊。
使用微主恩的好处
实现微额定体系结构带来了我下面列出的几个有用的好处：
- 成为技术不可知论 - 团队可以选择最适合他们的技术堆栈。
- 团队代码是孤立的 - 在孤立的环境和存储库中构建独立的应用程序
- 独立部署 - 微X架体系结构中的应用程序可以独立部署，这非常适合连续部署/交付
- 增量升级 - 可以逐步应用更改，而不会影响整个应用程序，而整个应用程序更容易测试，并且风险较小。
使用微额定的缺点
使用MicroFrontends Architecture具有好处，但也可能导致问题。看看下面的一些：
- 更大的复杂性 - 维护和对齐几个产品团队可能会更加困难。
- 术语 - 团队应具有独特的名称空间，不会彼此殖民。
- 共享上下文 - 在某些情况下，例如AUTH，Frontend应用程序可能需要共享已验证的用户的上下文，这可能是复杂的。
资源
查看以下资源以了解有关微注定架构的更多信息：