>头
鲍勃·迈尔斯是一名前端架构师,曾为从教育、出版到金融等领域的大型项目提供咨询.
微前端架构是一种设计方法 前端 应用程序被分解成独立的、半独立的“微应用程序”,松散地协同工作. 微前端概念隐约受到微服务的启发,并以微服务命名.
微前端模式的好处包括:
尽管最近微锋面得到了很多关注, 到目前为止,还没有单一的主导实现,也没有明确的“最佳”微前端框架. 事实上,根据目标和要求,有多种方法. 请参阅参考书目,了解一些比较知名的实现.
在本文中,我们将跳过许多关于微锋面的理论. 这是我们 不会 封面:
而不是, 我们将介绍一个专注于具体实现的微前端教程, 强调微前端架构中的重要问题及其可能的解决方案.
我们的实现叫做Yumcha. “yum cha”在广东话中的字面意思是“喝茶”,,但它的日常含义是“出去吃点心”.“这里的想法是,单个微应用程序 macroapp (我们将这样称呼他), 顶层应用程序)类似于点心午餐中拿出的各种小篮子.
我们有时会将Yumcha称为“微前端框架”.在当今世界,“框架”这个词通常指的是Angular、React、Vue.Js,或者其他类似的web应用的上层结构. 我们不是在说 这是一个框架 在所有. 我们称Yumcha为框架只是为了方便:它实际上更多的是一组工具和几个薄层,用于构建基于前端的微应用程序.
让我们深入思考一下如何定义一个macroapp和组成它的微应用. 标记一直是web的核心. 因此,我们的macroapp将通过以下简单的标记来指定:
Hello, micro-frontend app.
使用标记定义我们的macroapp让我们可以充分利用HTML和CSS的强大功能来布局和管理我们的微应用程序. 例如, 一个微应用程序可以位于另一个微应用程序之上, 或者在它的一边, 或者在书页的角落里, 或者在手风琴的一个窗格里, 或者躲起来,直到有事发生, 或者永远呆在后台.
我们已经为微应用程序命名了自定义元素
因为“门户”是微应用的一个很有前途的术语 门户网站的建议,这是定义用于微前端的标准HTML元素的早期尝试.
自定义元素我们应该如何实现
? 因为它是一个自定义元素,作为一个web组件,当然! We can choose from among a number of strong contenders for writing 和 compiling micro-frontend web components; here we will use LitElement,聚合物项目的最新版本. LitElement支持基于typescript的语法糖, 哪个为我们处理大部分自定义元素样板. 为了使
可用到我们的页面,我们必须包括相关的代码作为 ,如上所述.
但是什么
实际做的? 第一个近似是生成一个 iframe
与指定的来源:
呈现(){
return html``;
}
… 渲染
是标准的LitElement渲染钩子,使用它的 html
标记模板文字. 对于一些琐碎的用例来说,这个最小的功能可能已经足够了.
iframe
siframe
s是每个人都讨厌的HTML元素, 但实际上它们提供了非常有用的信息, 坚如磐石的沙盒行为. 然而,在使用时仍然有一长串的问题需要注意 iframe
S,对我们应用程序的行为和功能有潜在影响;
iframe
S在大小和布局方面有众所周知的怪癖.iframe
不管是好是坏.iframe
不会反映在网页的URL, 所以我们既不能剪切和粘贴url来获得复合应用的相同状态, 与他们也没有很深的联系.iframe
从外部,取决于我们的CORS设置, 可能需要通过 postMessage
协议.iframe
边界.iframe
边界或需要 iframe
有一个标题,他们可以宣布给用户.其中一些问题可以通过不使用来避免或减轻 iframe
S,这是我们在本文后面讨论的另一种选择.
在正方,是 iframe
会有自己的,独立的吗 Content-Security-Policy
(CSP). 还有,如果这个微程序 iframe
指向使用service worker或实现服务器端呈现, 一切都会如预期的那样进行. 方法指定各种沙箱选项 iframe
以限制其功能,例如能够导航到顶部框架.
一些浏览器已经发布或正在计划发布 加载=懒惰
属性 iframe
S,它延迟了在折叠下的加载 iframe
S,直到用户滚动到它们附近, 但这并没有提供我们想要的对延迟加载的细粒度控制.
真正的问题是 iframe
S是 iframe
是否需要多个网络请求来检索. 顶级 指数.html
收到, 它的脚本被加载, 它的HTML被解析——但随后浏览器必须发起另一个请求 iframe
的HTML,等待接收它,解析并加载它的脚本,然后呈现 iframe
的内容. 在许多情况下, iframe
js的JavaScript仍然需要启动, 调用自己的API, 并且只有在这些API调用返回并处理数据以供查看之后才显示有意义的数据.
这可能会导致不希望看到的延迟和渲染工件, 特别是当涉及多个微应用程序时. 如果 iframe
的应用程序实现了SSR,这将有所帮助,但仍然无法避免额外往返的必要性.
因此,我们在设计门户实现时面临的关键挑战之一是如何处理这种往返问题. 我们的目标是一个单一的网络请求应该关闭整个页面及其所有的微应用程序, 包括他们每个人能够预填充的任何内容. 这个问题的解决方案在于Yumcha服务器.
这里介绍的微前端解决方案的一个关键元素是设置一个专用服务器来处理微应用程序的组合. 该服务器将请求代理到每个微应用托管的服务器. 当然,设置和管理这个服务器需要一些努力. 一些微前端方法(如.g., single-spa)试图免除对这种特殊服务器设置的需要, 以方便部署和配置的名义.
然而, the cost of setting up 这 reverse proxy is more than offset by the benefits we gain; in fact, 有一些基于前端的微应用的重要行为是我们没有它就无法实现的. 有许多商业和免费的替代方案可以设置这样的反向代理.
反向代理除了将微应用程序请求路由到适当的服务器之外,还路由 macroapp 对macroapp服务器的请求. 该服务器以一种特殊的方式为合成的应用程序提供HTML. 在收到请求时 指数.html
通过代理服务器的URL,例如 http://macroapp.例子.com
,它检索 指数.html
然后在归还之前对它进行简单但关键的改造.
具体来说,要解析HTML
标记,这可以通过节点中可用的一个功能强大的HTML解析器轻松完成.js的生态系统. 使用 src
属性来
,则与运行微应用程序的服务器联系,并将其 指数.html
是否被检索——包括服务器端呈现的内容(如果有的话). 将结果插入到HTML响应中 or
标记,以免被浏览器执行.
此设置的优点首先包括,在第一次请求 指数.html
对于合成页面, 服务器可以从单个微应用服务器检索单个页面的全部内容(包括ssr呈现的内容), 如果有的话,送一个, 完成页面到浏览器, 包含可用于填充的内容 iframe
无需额外的服务器往返(使用未充分使用的 srcdoc
属性). 代理服务器还确保微应用程序从哪里提供服务的任何细节都不会被窥探. 最后,它简化了CORS问题,因为应用程序请求都是向同一个源发出的.
回到客户端
标记被实例化,并找到服务器在响应文档中放置的内容, 并在适当的时候呈现 iframe
并将内容分配给 srcdoc
属性. 如果我们不使用 iframe
S(见下),则其对应的内容
标记插入到自定义元素的影子DOM中, 如果我们用它, 或者直接内联在文档中.
在这一点上,我们已经有了一个部分功能的微前端应用程序.
这只是Yumcha服务器有趣功能的冰山一角. 例如, 我们想要添加一些功能来控制如何处理来自微应用服务器的HTTP错误响应, 或者如何处理响应非常缓慢的微应用程序——如果一个微应用程序没有响应,我们不想永远等待页面! 这些和其他话题我们将留待另一篇文章讨论.
Yumcha macroapp 指数.html
转换逻辑可以很容易地以无服务器的lambda函数方式实现, 或者作为服务器框架(如Express或Koa)的中间件.
回到客户端, 关于我们如何执行微应用,还有另一个方面对效率很重要, 延迟加载, 和无jank渲染. We 可以 生成 iframe
标记每个微应用程序,可以使用 src
属性——它发出另一个网络请求——或使用 srcdoc
属性,用服务器为我们填充的内容填充. 但在这两种情况下,其中的代码 iframe
马上就要开始了, 包括加载所有的脚本和链接标签, 引导, 以及任何初始API调用和相关数据处理——即使用户甚至从未访问过相关的微应用程序.
我们对这个问题的解决方案是,最初将页面上的微应用表示为微小的未激活存根, 哪一个可以被激活. 激活可以由微应用进入视野的区域驱动,也可以利用未被充分利用的区域 IntersectionObserver
API,或者更常见的是从外部发送的预通知. 当然,我们也可以指定立即激活微程序.
在任何情况下,当且仅当微应用程序被激活时 iframe
实际呈现,并加载和执行代码. 就我们使用LitElement的实现而言, 假设激活状态用an表示 激活
实例变量,我们会得到这样的东西:
呈现(){
if (!这.激活)返回html '{这.占位符}';
否则返回html '
`;
}
尽管组成宏应用程序的微应用程序根据定义是松散耦合的, 它们仍然需要能够相互沟通. 例如, 导航微应用需要发出通知,告知用户刚刚选择的其他微应用应该被激活, 而要激活的应用需要接收到这样的通知.
根据我们的极简主义思想,我们希望避免引入大量的消息传递机制. 相反,本着web组件的精神,我们将使用DOM事件. 我们提供了一个简单的广播API,它可以预先通知即将发生的事件的所有存根, 等待任何已请求激活该事件类型的事件被激活, 然后根据文档调度事件, 任何微程序都可以监听它. 鉴于我们所有的 iframe
S是同源的,我们可以从 iframe
到页面,反之亦然,以查找要针对其触发事件的元素.
在这个时代, 我们都期望spa中的URL栏表示应用程序的视图状态, 所以我们可以切, 粘贴, 邮件, 文本, 并链接到它以直接跳转到应用程序中的页面. 在微前端应用中, 然而, 应用程序状态实际上是状态的组合, 每个微应用一个. 我们如何表现和控制它?
解决方案是将每个微应用的状态编码为单个复合URL,并使用一个小的macroapp路由器,它知道如何将复合URL放在一起并将其分离. 不幸的是, 这需要在每个微应用中使用特定于yumcha的逻辑来接收来自macroapp路由器的消息并更新微应用的状态, 反过来,通知macroapp路由器该状态下的变化,以便更新复合URL. 例如,可以想象a YumchaLocationStrategy
对于Angular,或者
React元素.
iframe
情况下如上所述,在 iframe
S确实有一些缺点. 有两种选择:将它们直接内联地包含在页面的HTML中, 或者将它们放在影子DOM中. 这两种选择都反映了……的利弊 iframe
在某种程度上,但有时以不同的方式.
例如,单个微应用CSP策略必须以某种方式合并. 像屏幕阅读器这样的辅助技术应该比使用 iframe
假设它们支持影子DOM(但不是所有的都支持). 使用service worker的“作用域”概念来注册一个微应用的service worker应该是很简单的,尽管应用程序必须确保其服务人员以应用程序的名义注册, 不 "/"
. 没有与之相关的布局问题 iframe
应用于内联或阴影DOM方法.
然而, 使用Angular和React等框架构建的应用程序很可能不喜欢内联或隐藏在DOM中. 对于这些,我们可能会想要使用 iframe
s.
当涉及到CSS时,内联和阴影DOM方法是不同的. CSS将被清晰地封装在影子DOM中. 如果出于某种原因,我们确实想要与影子DOM共享外部CSS,我们将不得不使用 功能样式表 或者类似的东西. 使用内联微应用程序,所有的CSS将在整个页面中共享.
最后,实现了内联和影子DOM微应用的逻辑
很简单. 我们从服务器逻辑以HTML形式插入页面的位置检索给定微应用程序的内容 元素,克隆它,然后将它附加到LitElement调用的对象
渲染Root
,通常是元素的影子DOM,但也可以设置为元素本身(这
)用于内联(非阴影DOM)情况.
但是等等! 微应用服务器提供的内容是一个完整的HTML页面. 我们不能为微应用程序插入HTML页面 html
, head
, body
标签,放到macroapp的中间,我们可以?
我们解决这个问题的方法是利用 template
标记,从微应用服务器检索到的微应用内容被包装在其中. 事实证明,当现代浏览器遇到 template
标记,尽管它们不“执行”它,但它们确实执行了 解析 在这样做的过程中,它们删除了无效的内容,例如 ,
,
标记,同时保留其内部内容. 因此,
和
的标签
,以及内容
,都被保存了下来. 这正是我们想要在页面中插入微应用内容的目的.
微前端将在web应用生态系统中扎根,如果:(1)它们被证明是一种更好的架构方法, (b)我们可以找出如何以满足当今网络无数实际需求的方式实现它们.
就第一个问题而言, 没有人声称微前端是适用于所有用例的正确架构. 特别是, 由单个团队进行的绿地开发几乎没有理由采用微前端. 至于什么类型的应用在什么类型的环境下可以从微前端模式中获益最多,我将把这个问题留给其他评论员.
在实施和可行性方面, 我们已经看到有许多细节需要关注, 包括本文中甚至没有提到的几个问题—特别是身份验证和安全性, 代码重复, 和搜索引擎优化. 尽管如此, 我希望本文为微前端提供一个基本的实现方法, 经过进一步的细化, 能满足现实世界的需求吗.
微前端是一种新的模式,其中web应用ui(前端)由半独立的片段组成,这些片段可以由不同的团队使用不同的技术构建. 微前端架构类似于后端架构,后端由半独立的微服务组成.
微前端架构为微前端框架的结构元素提供了方法. 它还定义了它们之间的关系, 控制UI片段如何组装和交流,以实现最佳的开发人员和用户体验.
是的,在某种意义上他们可以. 微前端模式通常采用微前端的一个片段的方法, 可能作为一个微前端web组件实现, 与微服务配对以提供其UI.
微服务是体系结构的一个元素,其中应用程序被构建为互操作服务的集合. 如果前端采用微前端模式, 微服务可以与微前端配对.
微前端和web组件(自定义元素)可能在几个方面相关. Web组件是一种基于标记的自然方式,用于描述组成微前端应用程序的微应用程序. 微前端应用程序中的单个微应用程序本身可能是使用web组件构建的.
世界级的文章,每周发一次.
世界级的文章,每周发一次.
使用标记定义我们的macroapp让我们可以充分利用HTML和CSS的强大功能来布局和管理我们的微应用程序. 例如, 一个微应用程序可以位于另一个微应用程序之上, 或者在它的一边, 或者在书页的角落里, 或者在手风琴的一个窗格里, 或者躲起来,直到有事发生, 或者永远呆在后台.
\n\n我们已经为微应用程序命名了自定义元素
因为“门户”是微应用的一个很有前途的术语 门户网站的建议,这是定义用于微前端的标准HTML元素的早期尝试.
自定义元素我们应该如何实现
? 因为它是一个自定义元素,作为一个web组件,当然! We can choose from among a number of strong contenders for writing 和 compiling micro-frontend web components; here we will use LitElement,聚合物项目的最新版本. LitElement支持基于typescript的语法糖, 哪个为我们处理大部分自定义元素样板. 为了使
可用到我们的页面,我们必须包括相关的代码作为 ,如上所述.
但是什么
实际做的? 第一个近似是生成一个 iframe
与指定的来源:
呈现(){\n return html``;\n }\n
\n\n… 渲染
是标准的LitElement渲染钩子,使用它的 html
标记模板文字. 对于一些琐碎的用例来说,这个最小的功能可能已经足够了.
iframe
siframe
s是每个人都讨厌的HTML元素, 但实际上它们提供了非常有用的信息, 坚如磐石的沙盒行为. 然而,在使用时仍然有一长串的问题需要注意 iframe
S,对我们应用程序的行为和功能有潜在影响;
iframe
S在大小和布局方面有众所周知的怪癖.iframe
不管是好是坏.iframe
不会反映在网页的URL, 所以我们既不能剪切和粘贴url来获得复合应用的相同状态, 与他们也没有很深的联系.iframe
从外部,取决于我们的CORS设置, 可能需要通过 postMessage
协议.iframe
边界.iframe
边界或需要 iframe
有一个标题,他们可以宣布给用户.其中一些问题可以通过不使用来避免或减轻 iframe
S,这是我们在本文后面讨论的另一种选择.
在正方,是 iframe
会有自己的,独立的吗 Content-Security-Policy
(CSP). 还有,如果这个微程序 iframe
指向使用service worker或实现服务器端呈现, 一切都会如预期的那样进行. 方法指定各种沙箱选项 iframe
以限制其功能,例如能够导航到顶部框架.
一些浏览器已经发布或正在计划发布 加载=懒惰
属性 iframe
S,它延迟了在折叠下的加载 iframe
S,直到用户滚动到它们附近, 但这并没有提供我们想要的对延迟加载的细粒度控制.
真正的问题是 iframe
S是 iframe
是否需要多个网络请求来检索. 顶级 指数.html
收到, 它的脚本被加载, 它的HTML被解析——但随后浏览器必须发起另一个请求 iframe
的HTML,等待接收它,解析并加载它的脚本,然后呈现 iframe
的内容. 在许多情况下, iframe
js的JavaScript仍然需要启动, 调用自己的API, 并且只有在这些API调用返回并处理数据以供查看之后才显示有意义的数据.
这可能会导致不希望看到的延迟和渲染工件, 特别是当涉及多个微应用程序时. 如果 iframe
的应用程序实现了SSR,这将有所帮助,但仍然无法避免额外往返的必要性.
因此,我们在设计门户实现时面临的关键挑战之一是如何处理这种往返问题. 我们的目标是一个单一的网络请求应该关闭整个页面及其所有的微应用程序, 包括他们每个人能够预填充的任何内容. 这个问题的解决方案在于Yumcha服务器.
\n\n这里介绍的微前端解决方案的一个关键元素是设置一个专用服务器来处理微应用程序的组合. 该服务器将请求代理到每个微应用托管的服务器. 当然,设置和管理这个服务器需要一些努力. 一些微前端方法(如.g., single-spa)试图免除对这种特殊服务器设置的需要, 以方便部署和配置的名义.
\n\n然而, the cost of setting up 这 reverse proxy is more than offset by the benefits we gain; in fact, 有一些基于前端的微应用的重要行为是我们没有它就无法实现的. 有许多商业和免费的替代方案可以设置这样的反向代理.
\n\n反向代理除了将微应用程序请求路由到适当的服务器之外,还路由 macroapp 对macroapp服务器的请求. 该服务器以一种特殊的方式为合成的应用程序提供HTML. 在收到请求时 指数.html
通过代理服务器的URL,例如 http://macroapp.例子.com
,它检索 指数.html
然后在归还之前对它进行简单但关键的改造.
具体来说,要解析HTML
标记,这可以通过节点中可用的一个功能强大的HTML解析器轻松完成.js的生态系统. 使用 src
属性来
,则与运行微应用程序的服务器联系,并将其 指数.html
是否被检索——包括服务器端呈现的内容(如果有的话). 将结果插入到HTML响应中 or
标记,以免被浏览器执行.
此设置的优点首先包括,在第一次请求 指数.html
对于合成页面, 服务器可以从单个微应用服务器检索单个页面的全部内容(包括ssr呈现的内容), 如果有的话,送一个, 完成页面到浏览器, 包含可用于填充的内容 iframe
无需额外的服务器往返(使用未充分使用的 srcdoc
属性). 代理服务器还确保微应用程序从哪里提供服务的任何细节都不会被窥探. 最后,它简化了CORS问题,因为应用程序请求都是向同一个源发出的.
回到客户端
标记被实例化,并找到服务器在响应文档中放置的内容, 并在适当的时候呈现 iframe
并将内容分配给 srcdoc
属性. 如果我们不使用 iframe
S(见下),则其对应的内容
标记插入到自定义元素的影子DOM中, 如果我们用它, 或者直接内联在文档中.
在这一点上,我们已经有了一个部分功能的微前端应用程序.
\n\n这只是Yumcha服务器有趣功能的冰山一角. 例如, 我们想要添加一些功能来控制如何处理来自微应用服务器的HTTP错误响应, 或者如何处理响应非常缓慢的微应用程序——如果一个微应用程序没有响应,我们不想永远等待页面! 这些和其他话题我们将留待另一篇文章讨论.
\n\nYumcha macroapp 指数.html
转换逻辑可以很容易地以无服务器的lambda函数方式实现, 或者作为服务器框架(如Express或Koa)的中间件.
回到客户端, 关于我们如何执行微应用,还有另一个方面对效率很重要, 延迟加载, 和无jank渲染. We 可以 生成 iframe
标记每个微应用程序,可以使用 src
属性——它发出另一个网络请求——或使用 srcdoc
属性,用服务器为我们填充的内容填充. 但在这两种情况下,其中的代码 iframe
马上就要开始了, 包括加载所有的脚本和链接标签, 引导, 以及任何初始API调用和相关数据处理——即使用户甚至从未访问过相关的微应用程序.
我们对这个问题的解决方案是,最初将页面上的微应用表示为微小的未激活存根, 哪一个可以被激活. 激活可以由微应用进入视野的区域驱动,也可以利用未被充分利用的区域 IntersectionObserver
API,或者更常见的是从外部发送的预通知. 当然,我们也可以指定立即激活微程序.
在任何情况下,当且仅当微应用程序被激活时 iframe
实际呈现,并加载和执行代码. 就我们使用LitElement的实现而言, 假设激活状态用an表示 激活
实例变量,我们会得到这样的东西:
呈现(){\n if (!这.激活)返回html '{这.占位符}';\n 否则返回html '\n `;\n}\n
\n\n尽管组成宏应用程序的微应用程序根据定义是松散耦合的, 它们仍然需要能够相互沟通. 例如, 导航微应用需要发出通知,告知用户刚刚选择的其他微应用应该被激活, 而要激活的应用需要接收到这样的通知.
\n\n根据我们的极简主义思想,我们希望避免引入大量的消息传递机制. 相反,本着web组件的精神,我们将使用DOM事件. 我们提供了一个简单的广播API,它可以预先通知即将发生的事件的所有存根, 等待任何已请求激活该事件类型的事件被激活, 然后根据文档调度事件, 任何微程序都可以监听它. 鉴于我们所有的 iframe
S是同源的,我们可以从 iframe
到页面,反之亦然,以查找要针对其触发事件的元素.
在这个时代, 我们都期望spa中的URL栏表示应用程序的视图状态, 所以我们可以切, 粘贴, 邮件, 文本, 并链接到它以直接跳转到应用程序中的页面. 在微前端应用中, 然而, 应用程序状态实际上是状态的组合, 每个微应用一个. 我们如何表现和控制它?
\n\n解决方案是将每个微应用的状态编码为单个复合URL,并使用一个小的macroapp路由器,它知道如何将复合URL放在一起并将其分离. 不幸的是, 这需要在每个微应用中使用特定于yumcha的逻辑来接收来自macroapp路由器的消息并更新微应用的状态, 反过来,通知macroapp路由器该状态下的变化,以便更新复合URL. 例如,可以想象a YumchaLocationStrategy
对于Angular,或者
React元素.
iframe
情况下如上所述,在 iframe
S确实有一些缺点. 有两种选择:将它们直接内联地包含在页面的HTML中, 或者将它们放在影子DOM中. 这两种选择都反映了……的利弊 iframe
在某种程度上,但有时以不同的方式.
例如,单个微应用CSP策略必须以某种方式合并. 像屏幕阅读器这样的辅助技术应该比使用 iframe
假设它们支持影子DOM(但不是所有的都支持). 使用service worker的“作用域”概念来注册一个微应用的service worker应该是很简单的,尽管应用程序必须确保其服务人员以应用程序的名义注册, 不 \"/\"
. 没有与之相关的布局问题 iframe
应用于内联或阴影DOM方法.
然而, 使用Angular和React等框架构建的应用程序很可能不喜欢内联或隐藏在DOM中. 对于这些,我们可能会想要使用 iframe
s.
当涉及到CSS时,内联和阴影DOM方法是不同的. CSS将被清晰地封装在影子DOM中. 如果出于某种原因,我们确实想要与影子DOM共享外部CSS,我们将不得不使用 功能样式表 或者类似的东西. 使用内联微应用程序,所有的CSS将在整个页面中共享.
\n\n最后,实现了内联和影子DOM微应用的逻辑
很简单. 我们从服务器逻辑以HTML形式插入页面的位置检索给定微应用程序的内容 元素,克隆它,然后将它附加到LitElement调用的对象
渲染Root
,通常是元素的影子DOM,但也可以设置为元素本身(这
)用于内联(非阴影DOM)情况.
但是等等! 微应用服务器提供的内容是一个完整的HTML页面. 我们不能为微应用程序插入HTML页面 html
, head
, body
标签,放到macroapp的中间,我们可以?
我们解决这个问题的方法是利用 template
标记,从微应用服务器检索到的微应用内容被包装在其中. 事实证明,当现代浏览器遇到 template
标记,尽管它们不“执行”它,但它们确实执行了 解析 在这样做的过程中,它们删除了无效的内容,例如 ,
,
标记,同时保留其内部内容. 因此,
和
的标签
,以及内容
,都被保存了下来. 这正是我们想要在页面中插入微应用内容的目的.
微前端将在web应用生态系统中扎根,如果:(1)它们被证明是一种更好的架构方法, (b)我们可以找出如何以满足当今网络无数实际需求的方式实现它们.
\n\n就第一个问题而言, 没有人声称微前端是适用于所有用例的正确架构. 特别是, 由单个团队进行的绿地开发几乎没有理由采用微前端. 至于什么类型的应用在什么类型的环境下可以从微前端模式中获益最多,我将把这个问题留给其他评论员.
\n\n在实施和可行性方面, 我们已经看到有许多细节需要关注, 包括本文中甚至没有提到的几个问题—特别是身份验证和安全性, 代码重复, 和搜索引擎优化. 尽管如此, 我希望本文为微前端提供一个基本的实现方法, 经过进一步的细化, 能满足现实世界的需求吗.
\n\n