关于 2020 年微前端的思考

去年我发现“微前端”这个术语变得比以前更加普遍。

在后端开发者的世界里，将所有内容拆分成微服务已经越来越普遍。得益于 Docker 技术，将后端扩展为多个服务及其实例变得前所未有的简单。

但在前端开发人员的世界里，这种情况还不那么常见。

在这篇文章中，我想分享我的想法，说明为什么我认为从单体前端应用程序转向微前端方法可能是件好事。

为什么？

对于那些多年来一直使用单片架构构建网站或 Web 应用程序的前端开发人员来说，微前端方法感觉有点不对劲。（嗯，这是我发现它时的第一印象）。

单体前端的问题

当你思考我们在使用单片前端应用程序时所面临的挑战时：

• 与多人/团队合作更加困难
• 构建时间长
• 在不知情的情况下覆盖样式
• 当 API 发生重大变化时，需要部署整个应用程序

当你刚开始搭建单个网站时，这不是什么大问题。但随着组织规模的扩大，参与其中的人员数量就会成为一个挑战。

微前端需要解决的问题

切换到微前端方法可以解决其中的一些问题。

• 易于小规模部署
• 更短的构建时间
• 更容易与多人/团队合作
• 重大 API 变更仅需 1 次小型部署

但这需要开发团队转变思维方式。此外，改变前端架构还需要一些额外的工作。

如何

幸运的是，我们并不是第一个在单片前端架构中遇到这些挑战的开发人员。

大公司引领潮流

Spotify、Klarna、Zalando、Upwork、Allegro、HelloFresh、AirBnB 和 Facebook 等大公司也经历过这些挑战。

因此，他们在这方面做出了许多开拓性的努力，并找到了一些很酷的方法来解决问题。

• Zalando构建了Mosaic9。查看他们的演讲：Zalando Tech 上的 Mosaic 微服务
• Klarna在 HN 上解释了他们如何处理这个问题
• Upwork发表了一篇博文：通过微前端实现 Upwork 现代化
• Allegro撰写了一篇博文：在微服务架构中管理前端
• HelloFresh撰写了一篇博文：HelloFresh 的前端微服务
• AirBnB创建了一个名为HyperNova的工具来提供服务器端 JavaScript 视图

技术

如果您查看所有大公司的帖子，您就会看到一些关于如何从技术上处理微前端的技术。

• 元框架：Single-SPA，此框架允许您在运行时组合多个 JavaScript 框架/库，而无需刷新页面。
• 不同 URL 上的多个 SPA：这是拥有多个微前端的最简单方法
• IFrame
• Web 组件：使用 JavaScript 包装器将 Angular 和 React 组件转换为 Web 组件，并将它们并排运行。Chris Kitson撰写了一篇精彩实用的博客文章：使用 Web 组件创建微前端（支持 Angular 和 React）

什么时候

但问题是，“什么时候切换到微前端是个好主意？” 嗯，我认为相对简单，当你构建一个小型网站时，坚持使用单体架构。当你构建一个大型应用程序，与大量人员/团队合作，并使用“微服务”作为后端架构时，你绝对可以从微前端方法中受益。

谢谢

感谢你读到这里😅。希望这篇文章能为你探究微前端提供一些素材。