我们有机会利用其所有好处，如可扩展性、技术独立性和可维护性。另一方面，从长远来看，我也注意到了一些严重的问题。
这意味着我们不仅学到了微型前端带来的好东西，还学到了它们的主要缺点。经过深入研究它们，看看我们应该做些什么来避免或解决它们。
1.冗余依赖项
根据定义，每个微型前端应用程序都独立于其他应用程序。换句话说，微前端架构涉及多个前端应用程序，该应用程序也应该在没有其他应用程序的情况下工作。为了做到这一点，每个人都有自己的依赖项。因此，从整体来看，我们正在失去使用软件包管理器的好处。事实上，整个应用程序可能会由同一库的许多版本组成，分散在微型前端。
这无疑是一个问题，因为它使 Web 应用程序不必要的大于其整体应用程序。这落在最终用户身上，他们被迫下载更多数据。此外，这会影响渲染时间，从而影响 Google Web Vitals 的分数，也会影响网站的搜索引擎优化。
如何解决这个问题
创建一个包含所有共享库的微前端。然后更新微前端，使其构建的软件包从此共享项目导入所需的库。
2.冲突和重叠的风格
同样，技术和团队独立性很棒，但它也会带来一些问题。在处理造型时尤其如此。事实上，从商业角度来看，每个微型前端都不能有自己的风格。这是因为你绝对不希望应用程序看起来由许多补丁组成。在风格、用户界面和用户体验方面，一切都应该保持一致。
这些问题可能会对你的品牌声誉产生负面影响。此外，最终用户将为这些不一致之处付出代价，特别是在用户界面方面。
如何解决这个问题
当涉及到UI和用户体验时，唯一可能的解决方案是确保每个团队都与对方交谈，并考虑到相同的结果。此外，在上述共享微型前端项目中添加样式组件可能会有所帮助。尽管如此，这将使每个微型前端应用程序都依赖于此，并因此破坏了基本的独立性。但至少它会防止你的整个应用程序看起来异构。
3.性能差
因此，在同一页面上运行多个 JavaScript 前端应用程序将减慢整个应用程序的速度。这是因为每个框架实例都需要 CPU、RAM 和网络带宽方面的资源。
此外，请记住，在测试与他人隔离的微型前端时，你可能不会注意到这一点。当一个框架的多个实例同时运行时，问题就开始了。这是因为，如果它们独立运行，它们不必像部署时那样共享底层机器的资源。
如何解决这个问题
解决这个问题的一个想法是加强团队沟通，以避免做出同样的电话和阐述。然后，将结果存储在每个微型前端都可以访问的地方，或允许他们在执行繁重操作之前进行通信，以验证之前是否已经检索或生成了相同的数据。
4.前端之间的通信
最初，除极少数情况外，你不需要让微型前端进行通信。这可能会愚弄你，让你认为它总是这样。此外，尽管微型前端架构模式是关于独立的，但这与通信相反。
当整个应用程序增长时，使你的微型前端能够毫不费力地相互通信可能会成为优先事项。最重要的是，如果你想一遍又一遍地重复相同的操作，特别是当它们不是幂等的话。
此外，如上所述，沟通对于实现更高的性能是必要的。例如，你不希望你的应用程序进行两次相同的API调用来检索相同的数据，并不必要地减慢服务器的速度。
如何解决这个问题
解决方案是根据存储在 cookie 或 localStorage 中的共享状态或自定义定义的事件实现自定义消息层。你可以想象，实施它需要付出代价，并且很快就会变得复杂和繁琐。此外，考虑到沟通会带来开销。因此，你必须确保你正在构建的内容将带来真正的好处，并且不会进一步减慢你的应用程序速度。
5.团队之间的沟通问题
团队中的沟通可能是一个问题。这是因为让多个成员在不同的代码库上工作意味着找到可重用的功能、功能和实用程序变得更加困难。这在代码可发现性方面很糟糕，因此在可重用性方面也很糟糕。换句话说，最终可能会在不同的微前端重复实现相同组件。
如何解决这个问题
团队相互交谈并保持最新状态对项目的成功至关重要。因此，培养沟通文化必须是关键要素之一。
开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 3 天，点击查看活动详情
