预测微前端的未来

微型前端架构的主要挑战之一是回答这个问题：微型前端有多 “微”？

这是一个很多组织都面临的问题，在现实中，并不是只有一个答案，我们需要了解背景，组织结构和规模，以及团队之间的沟通流程。

在与多个从事分布式架构工作的团队接触后，我看到很多时候 "分布式组件 "比微前端的实施更重要。

通过分布式组件，领域知识在容器和 "微前端 "之间，甚至在容器和多个 "微前端 "之间被共享。

我们仍在努力寻找正确的边界，有时对我们在实现微前端时应该如何解释微前端缺乏理解。

我认为这种理解是走向更好的成熟的必要步骤，掌握应用业务子域不是一件容易的事，需要我们对正在构建的应用有深入的了解。

然而，我认为有一个潜在的解决方案来缓解这一挑战。

在前期投入更多的时间在白板上，与组织的多个部分一起修改如何在不影响用户体验的情况下分割我们的业务领域是必须的。

当我们从这些会议中走出来的时候，我们应该有足够的信心来启动这个项目，并定期审查我们的决定，以确保我们最初的假设对于实现我们的目标仍然有效。

请记住，我们不可能在前期捕捉到所有的东西，今天的业务和组织很可能在6或12个月后发生变化，所以我们应该定期重新审视我们的微观前沿界限。

另外，永远不要忘记组织结构和软件架构之间的联系，意识到这一点并在我们的设计决策中考虑到这一点很重要。

微前端的通信

当我们在同一个视图中拥有多个微前端时，在某些时候它们需要相互沟通。

在我为设计微前端而创建的心理模型中，鼓励使用发布-订阅模式在微前端之间进行通信，以执行微前端之间的边界，避免或至少减少设计时的耦合性，从而导致更多的自主团队。

为了在技术上实现这种模式，有几种选择，如自定义事件、事件发射器库，甚至是反应式流。

在过去的几个月里，出现了一个重要的需求，我在开始的时候并没有太强调，可能是因为我把它当成了理所当然，但这绝对是需要注意的。

就像后台的事件驱动架构一样，对事件有一个清晰的模式将有助于避免在整合阶段出现错误。此外，模式还可以让那些不直接从事代码库工作的技术人员清楚地了解特定应用程序内部发生了什么。

我在我关注的众多Slack频道中发现了这个事件总线库，它绝对有助于在松散耦合的元素（微前端，但不限于此）之间实现更有条理的通信。

考虑到微前端是一个分布式架构，需要有一个更正式的API或事件管理。

API或事件是团队互动的方式，不仅仅是在微前端。

我们必须明白，这些做法不仅仅是帮助开发者在发送事件时避免错误，而且还能促进团队之间的讨论，提供清晰的意图。

我希望在未来，当我们有大量使用松耦合通信策略的大型应用时，会有更多的努力来简化开发者的体验。

如果有一个事件注册表，在我们每次开发新的微前端之间的交互时都能参考，那该有多好？

服务器端渲染（SSR）

服务器端渲染架构是过去几个月中创新较多的，想想Next.js或者React 18背后的团队对服务器组件的投资。

我们在微型前端也有一些有趣的解决方案，比如Next.js的 module federation for Next.js, Piral, TailorX, ILC 等等。

对于SSR微前端的应用，我们应该开始更深入地研究一些课题。

这些是我到目前为止发现的差距：

微前端的发现：就像微服务的服务发现模式，但应用于前端。使用这种模式，我们可以动态地组成微前端，而不需要对系统中的端点有任何静态的参考。

想象一下，一个微前端基础设施自我注册到一个发现服务，一个UI组合器从发现服务中检索微前端，而不是与微前端本身进行点对点的连接。
云计算上的参考架构：在如何使用流行的云供应商构建SSR微前端架构方面，缺乏指导。这是一个可以较快解决的摩擦点，我希望能尽可能地提供帮助。
利用微前端的无服务器范式。我相信无服务器可以提供一个很好的开发速度，将基础设施管理委托给云供应商。同时，我们必须转变思路，了解我们应该为微前端等特定工作负载利用哪些服务。

例如，我认为使用像AWS Step Functions这样的服务来简化微前端的创建是有价值的，因为它提供了与整个AWS生态系统的巨大集成。这使我们能够接受一种低代码模式，从长远来看，这将简化维护。

这是我们可以在云上使用的许多模式之一，但用微前端探索这些模式可能是非常迷人的（至少对我来说是这样）。
一种框架无关的React服务器组件方法：当后端数据发生变化时，有一种机制可以使用SSR原子化地重新加载视图的一部分，并与客户端微前端无缝集成。这将允许混合架构混合CSR和SSR，为每个微前端使用正确的方法。也许我们今天就可以创建这样的机制，但像React 18那样有一个光滑的实现将是最终的目标。

正如你所看到的，有很多机会摆在我们面前，有些是比较具体的，比如参考架构，有些是比较长期的，比如不可知的React服务器组件方法。

在这个列表中，我的重点将是涵盖参考架构以及对使用无服务器范式的微前端的调查。我已经开始研究参考架构的原型，在无服务器方面我也有一些有趣的原型。敬请关注进一步的更新。

局部水化hydration

性能是每个前端应用程序的关键，包括微型前端的。

我已经很久没有听说过 "岛屿架构 "的概念了，然而，我相信最终这种架构由于其原则和特点，可能属于微前端的范畴。

岛屿架构引入的有趣技术是通过利用部分水化来提高我们服务器端渲染应用程序的性能。

简而言之，不是对整个页面进行水化，而是只对用户可见的 "岛屿 "立即进行水化，其他的将在用户看到它们时进行水化。

局部水化并不是一个新的技术，从2019年开始就有了（如果我记得很清楚的话），但是我没有在微前端应用中看到任何关于这个技术的参考。考虑到微前端的性质和部分水化的工作方式，我相信这种技术应该会得到更多的青睐，以进一步优化我们的SSR微前端应用。

微型前端和边缘计算

当我们谈论边缘的微前端时，我们通常会想到Edge-Side Includes（ESI）标记语言。

这次我指的是许多CDN正在提供的计算能力，如边缘的AWS Lambda或Cloudflare workers。

边缘技术正在快速发展，因此部分应用可以被移到边缘，改善我们解决方案的延迟和可扩展性。

然而，在许多网络应用中，我们不能只考虑使用多个微前端生成HTML页面的计算工作，我们还需要考虑整个应用的复杂性。

计算通常是当今 "最容易 "解决的问题，当涉及到数据引力（数据库、多区域数据复制、全球基础设施的写与读、数据复制延迟…），或认证时，通常是集中在云基础设施的特定区域或甚至是内部的数据中心，并有良好的安全性。

的确，SSR微前端应用可以从边缘计算中受益，但它们需要访问大量的其他资源（数据、认证、缓存…），这些资源在边缘还不能完全使用。

我们不能真正考虑使用边缘的全部力量，除非我们有一个非常好的封装的工作负载，不需要任何这些外部依赖性。

我相信在未来我们会更多地采用边缘技术，但同时我认为我们必须更好地理解边缘技术在哪些方面可以对我们的工作负载产生真正的影响，而不仅仅是因为与边缘节点一起工作是 "很酷 "的（有炒作驱动的开发吗？

在我看来，在不久的将来，边缘计算将与微型前端有很大的关系，特别是对于提高应用程序的性能，但它并不像现在看起来那么简单。

部署

在微服务中，有一套统一的做法来降低新的微服务版本的部署风险，如功能标志、蓝绿部署和金丝雀发布。

在过去的12个月中，我没有看到在微前端中实施类似的做法，这部分是来自于功能标志，它看起来是许多团队的知名模式。

我相信一个能给开发团队带来信心的部署策略是必须的。

在一个分布式系统中，持续部署往往是一个现实，我们必须为开发人员创造一个安全网，使他们能够快速迭代，将他们的代码从他们的笔记本电脑转移到生产环境中，而不会有引入所有用户体验的错误的风险。

对于SSR微前端，我们可以很容易地重用现有的工具和实践，利用这些机制之一来发布我们的基础设施，尽管，这些策略往往不被客户端渲染微前端应用程序所接受。

我们有几种方法可以实现它们，客户端、服务器端甚至是边缘。

我的建议是尽快实施这些策略中的一种，因为它们可以为你的团队创造一个更安全的环境，其结果可能会让你吃惊…在积极方面

路由

与部署策略严格相关的是，客户端渲染的微前端应用程序缺乏一个坚实的路由策略。

所有的实现都在使用我们用来实现单体架构的路由库。

相反，我相信我们可以做得比这更好!

当我们把路由库和前面描述的部署策略混合在一起时，我们可以有一个非常聪明的路由，考虑到较新的微前端版本，不同的环境，甚至是不同的用户角色。

我们也可以有一些工具，逐渐增加对版本的流量，并以同样的方式执行回滚。

例如，当我们在AWS中开发容器或无服务器工作负载时，我们可以通过几行配置轻松设置我们喜欢的部署策略。

应用程序外壳中的路由可以通过外部JSON轻松协调，提供不同的可能性，而不需要将这些信息集成到应用逻辑中。

最后，当这种静态的JSON与部署逻辑相结合时，我相信这种组合可以带来很多价值，减少新版本的风险，并允许根据你的企业想要实现的任何逻辑进行动态配置。

路由和部署绝对是我感兴趣的领域。在接下来的几个月里，我将投入时间来消除无差别的繁重工作，让团队能够更好地控制他们的部署和路由。我希望我能够尽早分享我的工作内容，因为工作组对这两个主题非常兴奋

微前台的管理

我没有探索（还没有）这个领域，但我有一个工具清单，可以尝试了解微前端的优点和缺点。

我的重点将主要放在monorepo上，因为我相信对于poly-repo，我们不需要额外的工具来管理代码，就像在同一个仓库中有多个独立项目时一样。

目前，这些工具引起了我的注意：

Turborepo
PNPM
Projen

我相信所有这些工具都有一些功能，可能有助于构建一个单一的战略，改善开发者的经验。

这是今年的一个扩展目标，我不确定我是否能够投入足够的时间来审查每一个工具，但我一定会密切关注这个空间，因为我相信有更多未开发的机会来进一步改善开发者的体验。

我们非常欢迎任何可以尝试的工具的建议，特别是如果你在分享你的经验时可以提供一个简短的评论。

总结

正如你所看到的，在微前端生态系统中仍有很多地方需要覆盖，但我们在过去几年中取得了巨大的进步。

对我来说，这是一个超级令人兴奋的机会，可以为一个 "年轻 "的架构塑造许多改进的领域，在全球企业组织中获得成功。

我相信还有更多的东西需要发现，我希望这种快速的采用会给分布式UI架构中哪些是可行的，哪些是不可行的带来新的见解。

预测微前端的未来 - luca相关推荐

乾坤微前端_最全汇总之微前端知识和实战（EMP技术方案）
我们团队在早早聊的B站直播间分享了EMP微前端---团队半年以来的技术果实.分享的内容全在这里,会讲述微前端的由来,解决的问题,以及EMP微前端方案的不同之处,更有四个实战项目的总结,欢迎大家一起探讨 ...
mac webpack 版本_晓前端周刊第48期：EMP面向未来微前端方案正式开源了！玩转 webpack，使你的打包速度提升 90%；...
业界动态苹果最大杀招:iPhone App 已能在电脑运行近日网友反馈,苹果 App Store 中大量应用在兼容性一栏中显示:已支持运行 macOS 11(及以上版本)的 Mac 电脑.这意味着 ...
微前端(Micro Frontend ) 落地实施的一些具体例子
前文微前端概述(Micro Frontends) 以及相比单体应用,微前端能带来什么好处简单介绍了微前端的概念,本文来看一个具体的应用例子. 原文地址想象一个网站,客户可以在其中订购外卖食品.从表 ...
bootstrap跟vue冲突吗_知道微服务，但你知道微前端吗？
在 toB 的前端开发工作中,我们往往就会遇到如下困境: 工程越来越大,打包越来越慢团队人员多,产品功能复杂,代码冲突频繁.影响面大内心想做 SaaS 产品,但客户总是要做定制化不同的团队可能有 ...
微前端在美团外卖的实践
来自:美团技术团队微前端是微服务理念在前端的应用.之前美美给大家介绍过微前端在美团HR系统和美团闪购的实践文章. 今天的文章来自美团外卖广告团队,他们参考业界优秀方案,同时也深度结合了广告端实际业务 ...
乾坤微前端_微前端架构初探以及我的前端技术盘点
前言最近几年微前端一直是前端界的热门议题, 它类似于微服务架构, 主要面向于浏览器端,能将一个复杂而庞大的单体应用拆分为多个功能模块清晰且独立的子应用,且共同服于务同一个主应用.各个子应用可以独立运 ...
前端dashboard框架_微前端在网易七鱼的实践
一.前言网易七鱼是提供围绕客户服务与智能营销的 SaaS 平台.在七鱼业务中,有在线系统.呼叫系统.机器人.工单系统.数据大屏等业务线,它们分布在两个业务端,管理端和客服端.这两个端的功能框架类似, ...
前端iframe 能指定本地网页吗_微前端的技术拆分方式
路由分发式通过HTTP服务器的反向代理功能,将请求路由到对应的应用上特点采用的最多.最容易的"微前端"方案并非一个整体,每当用户从A应用转换到B应用的时候,往往需要刷新一下 ...
Angular、Vue、React 和前端的未来
最近社区针对框架的争论,从发文互怼再到粉丝站队再到大漠穷秋准备离职,令人唏嘘不已.不知从何而起,前端圈已经逐步变成了前端娱乐圈.越来越多的人开始站队 Angular.Vue.React,仅仅围绕这些库 ...

预测微前端的未来 - luca

预测微前端的未来 - luca相关推荐

最新文章

热门文章