它们是我们可以在前端世界

rmamin

人们在评估应用程序并思考“哦，是的，这将是转向微前端架构的良好候选者”时应该寻找一些明显的迹象吗？

卢卡：是的，所以我的建议首先是我不会启动一个带有微前端的绿地项目，除非我们确切地知道它应该如何构建。通常，您不太可能拥有此信息，因为，特别是如果您有一个新平台或一个新项目，并且这是您第一次从事此工作，那么找到此信息可能会很困难。通常我建议从现有的单页应用程序架构开始，然后对其进行改进。特别是我发现，我认为将微前端用于遗留应用程序，或者当我们想要替换应用程序的特定部分时，或者当我们有一个想要为多个团队发展和扩展的项目时，这就是三个用例我觉得非常适合微前端架构。显然这并不意味着从现在开始一切都应该微前端，因为微前端根本不是灵丹妙药。

卢卡：中利用的附加架构。到目前为止，我们已经有了一定数量的架构，现在我们 电报号码数据 有了额外的架构。但这是一个很大的挑战，因为显然你需要，如果在服务器端渲染或单页面应用程序之前，有明确的模式被探索，然后由多个框架等实现。目前，微前端是一种做事的方式。但添加决策框架可能应该允许人们针对他们的用例做出正确的决策。因为对于微前端是什么以及应该如何使用它们，通常存在很多误解。很多人都在想，也许可以说，我不知道，在一个视图或其他事物中拥有太多的库是邪恶的。

卢卡：现实是你需要深入理解这个概念，了解如何实现它，然后你才能开始研究它。我完全同意，存在技术挑战，并且您必须做出很多决定，并且您不能立即开始让前面的编辑​​器编写代码并思考，好吧，现在我正在创建一个微前端建筑学。因为您需要理解概念、理解上下文并围绕它进行创建和治理，因为复杂性不仅仅是编写代码，还需要理解 CICD 部分、SEO 部分等中的所有部分如何组合在一起。



卢卡：因此，微前端确实提供了一定程度的灵活性，并且需要付出大量努力来定义治理权。因为当你有正确的治理时，一切都会顺利。不幸的是，我经常说，我看到一些公司没有在治理方面花费足够的时间，例如理解 CICD，因为他们认为这并不重要。但对于微前端来说，就像微服务一样，拥有正确的自动化可以让你加快开发速度。如果您没有在自动化方面花费足够的时间，您可能会面临负担大于收益的风险。

德鲁：我想这就像网络开发世界中的许多事情一样，人们在真正理解问题之前就面临着钻研技术解决方案的危险。听起来微前端在很大程度上需要看到问题，然后实施解决方案才能知道要解决什么问题。我想微前端的本质使得它很容易开始集成到现有的应用程序中，发现一个小问题并将其替换为微前端以解决该问题。