网站建设公司未来方向,网站seo新手,c2c网站的主要功能,wordpress 主题king文章目录 一、微前端简介二、微前端的优势1. 高度模块化2. 独立部署3. 易于扩展4. 技术栈无关5. 独立升级 三、微前端的原理四、微前端案例思路《微前端实战》编辑推荐内容简介作者简介目录前言/序言 随着互联网行业的快速发展#xff0c;前端应用的规模和复杂度也在不断增加。… 文章目录 一、微前端简介二、微前端的优势1. 高度模块化2. 独立部署3. 易于扩展4. 技术栈无关5. 独立升级 三、微前端的原理四、微前端案例思路《微前端实战》编辑推荐内容简介作者简介目录前言/序言 随着互联网行业的快速发展前端应用的规模和复杂度也在不断增加。为了应对这种挑战越来越多的企业和开发者开始探索新的前端架构模式。微前端作为一种新兴的前端架构模式凭借其高度模块化、独立部署、易于扩展等特点逐渐成为了业界的热门话题。本文将通过一个实际案例详细介绍微前端的概念、原理以及在实战中的应用。
一、微前端简介
微前端Micro Frontends是一种将大型单页应用拆分为多个独立的小型应用的技术方案。每个小型应用都可以独立开发、部署和运行它们之间通过共享公共资源如样式、组件等来实现数据和状态的同步。微前端的核心思想是将前端应用分解为一组可独立维护、独立部署的子应用从而提高开发效率、降低维护成本同时保证系统的灵活性和可扩展性。
二、微前端的优势
1. 高度模块化
微前端将大型应用拆分为多个小型应用每个应用负责一个特定的功能或模块。这种模块化的设计使得开发者可以更加专注于某个功能的开发提高开发效率。
2. 独立部署
每个微应用都可以独立部署无需对整个应用进行整体部署。这大大简化了部署过程降低了部署风险。
3. 易于扩展
当需要添加新功能时只需开发一个新的微应用并将其集成到主应用中而无需修改现有的代码。这使得系统具有良好的可扩展性。
4. 技术栈无关
微前端允许每个微应用使用不同的技术栈这为团队提供了更大的技术选择空间同时也降低了技术选型的风险。
5. 独立升级
当某个微应用需要升级时只需对该应用进行升级而不会影响其他应用。这有助于保持整个系统的稳定和可靠。
三、微前端的原理
微前端的核心原理是通过定义一个容器来承载多个独立的微应用。这个容器负责管理各个微应用之间的通信和资源共享。具体来说微前端主要包括以下几个部分 主应用主应用是整个系统的入口它负责加载和管理各个微应用。主应用通常包含一个容器元素用于承载各个微应用的内容。此外主应用还需要提供一些基础设施服务如路由管理、状态管理等。 微应用微应用是主应用中的一个子应用它可以独立开发、部署和运行。每个微应用都包含一个容器元素用于承载该应用的内容。此外微应用还需要提供一些与主应用交互的接口如共享资源、通信等。 通信机制微前端需要实现各个微应用之间的通信和资源共享。这通常通过定义一套统一的通信协议和API来实现。例如可以使用自定义事件、消息队列等方式来实现微应用之间的通信可以使用Webpack、Rollup等打包工具来实现资源的共享和提取。
四、微前端案例思路
下面我们通过一个简单的案例思路来模拟如何使用微前端技术构建一个高效的前端应用。假设我们要开发一个包含多个子功能的在线教育平台如课程管理、在线考试、学习社区等。我们可以采用以下步骤来实现这个系统 拆分功能模块首先我们需要将整个在线教育平台拆分为多个独立的功能模块如课程管理模块、在线考试模块、学习社区模块等。每个模块都可以作为一个独立的微应用进行开发和维护。 设计通信协议为了实现各个微应用之间的通信和资源共享我们需要设计一套统一的通信协议和API。例如我们可以定义一个emit方法来触发自定义事件以及一个on方法来监听自定义事件我们还可以使用Webpack的CommonsChunkPlugin插件来实现公共资源的提取和共享。 开发主应用主应用是整个在线教育平台的入口它负责加载和管理各个微应用。主应用需要提供一个容器元素来承载各个微应用的内容并提供一些基础设施服务如路由管理、状态管理等。此外主应用还需要实现与各个微应用的通信和资源共享。 开发微应用每个微应用都是一个独立的功能模块它可以独立开发、部署和运行。每个微应用都需要提供一个容器元素来承载该应用的内容并提供一些与主应用交互的接口如共享资源、通信等。此外微应用还需要实现自身的业务逻辑和界面展示。 集成测试在完成各个微应用的开发后我们需要对整个系统进行集成测试确保各个微应用之间的通信和资源共享正常工作。此外我们还需要对整个系统的性能、稳定性等进行测试和优化。 《微前端实战》 编辑推荐
就像微服务为后端系统带来了灵活性和可维护性微前端也为基于浏览器的应用程序提供了同样的优势。你可以将项目设计为包含多个单独的组件每个组件中包括各自的接口、逻辑和存储功能这样就可以独立开发这些组件并在浏览器中组合使用它们。
《微前端实战》一书指导读者将微服务方法应用于前端领域。本书首先会介绍微前端的核心设计思想之后你将亲手创建一个电商应用程序并在开发过程中处理一些实际问题如服务端组合和客户端组合、路由、确保外观和交互的一致性等。最终你将深入了解团队工作流模式这种模式能够化地突显独立开发应用程序组件的优势。
内容简介 将多个独立的应用程序组合成一个统一的前端应用程序 将基于不同框架的代码组合在一起 浏览器端组合、服务端组合以及路由 高效的开发团队实践和项目工作流
作者简介
Michael Geers是一名软件开发者专注于用户界面相关开发领域。他从十几岁起就开始为网站开发软件。在过去的几年里他参与过多个垂直架构的项目在多个国际性会议上分享了自己的经验并在杂志上发表了一系列相关的文章。目前他仍在持续运营https://micro-frontends.org站点。
目录
第Ⅰ部分 微前端初体验第1章 什么是微前端 31.1 概览图 41.1.1 系统和团队 51.1.2 前端 81.1.3 前端集成 111.1.4 公共话题 131.2 微前端解决了哪些问题 141.2.1 优化功能开发 141.2.2 不再有前端巨石架构 151.2.3 适应变化 161.2.4 自主的优势 191.3 微前端的缺点 211.3.1 冗余 211.3.2 一致性 211.3.3 异质性 221.3.4 更多的前端代码 221.4 使用微前端的合理时机 231.4.1 适合大中型项目 231.4.2 在Web应用程序中使用效果最好 231.4.3 效率与开销 241.4.4 微前端不适用的场景 251.4.5 谁在使用微前端 261.5 本章小结 26第2章 我的第一个微前端项目 292.1 The Tractor Store简介 302.1.1 准备开始 302.1.2 运行书中的示例代码 322.2 通过链接进行页面跳转 352.2.1 数据所有权 352.2.2 团队契约 362.2.3 如何实现 372.2.4 处理URL的变化 402.2.5 优点 412.2.6 缺点 422.2.7 何时使用链接集成技术 422.3 通过iframe进行组合 422.3.1 如何实现 432.3.2 优点 452.3.3 缺点 452.3.4 何时使用iframe集成技术 462.4 内容预告 462.5 本章小结 47第Ⅱ部分 路由、组合与通信第3章 使用Ajax进行组合与服务端路由 513.1 通过Ajax进行组合 523.1.1 如何实现 533.1.2 样式与脚本的命名空间 553.1.3 声明式地加载h-include 593.1.4 优点 593.1.5 缺点 613.1.6 何时使用Ajax集成 623.1.7 总结 623.2 通过Nginx实现服务端路由 633.2.1 如何实现 663.2.2 资源的命名空间 693.2.3 路由配置的方法 703.2.4 基础设施的归属 713.2.5 何时应使用单个域名 733.3 本章小结 73第4章 服务端组合 754.1 通过Nginx和服务端包含(SSI)进行组合 764.1.1 如何实现 774.1.2 更少的加载次数 804.2 处理不可靠的片段 814.2.1 可分离的片段 824.2.2 集成Near You片段 834.2.3 超时和回退 844.2.4 回退内容 864.3 深入研究标签的组装性能 874.3.1 并行加载 874.3.2 嵌套的片段 884.3.3 延迟加载 894.3.4 首字节时间和流式输出 904.4 其他解决方案概述 924.4.1 Edge-Side Includes 924.4.2 Zalando Tailor 934.4.3 Podium 954.4.4 哪种方案更适合 1024.5 服务端组合的优缺点 1044.5.1 优点 1044.5.2 缺点 1044.5.3 使用服务端集成的时机 1054.6 本章小结 106第5章 客户端组合 1075.1 使用Web Component封装微前端 1085.1.1 如何实现 1105.1.2 将框架封装在Web Component内 1155.2 使用Shadow DOM实现样式隔离 1175.2.1 创建shadow root 1175.2.2 样式隔离 1185.2.3 何时使用Shadow DOM 1205.3 使用Web Component进行组合的优缺点 1215.3.1 优点 1215.3.2 缺点 1225.3.3 使用客户端集成的时机 1225.4 本章小结 123第6章 通信模式 1256.1 用户界面通信 1266.1.1 父级页面到片段 1276.1.2 片段到父级页面 1316.1.3 片段到片段 1356.1.4 使用Broadcast Channel API发布/订阅 1406.1.5 UI通信更适合什么场景 1426.2 其他通信机制 1436.3 本章小结 148第7章 客户端路由和应用程序容器 1497.1 应用程序容器中的扁平化路由 15217.2 双层路由的应用程序容器 1627.3 single-spa元框架的简述 1717.4 来自统一单页面应用的挑战 1787.5 本章小结 183第8章 组合和多端渲染 1858.1 结合使用服务端和客户端组合 1878.2 何时适合采用多端组合 1958.3 本章小结 197第9章 适合我们项目的架构 1999.1 复习专业术语 2009.2 复杂度的比较 2069.3 是构建网站还是应用程序 2089.4 选择正确的架构和集成技术 2119.5 本章小结 216第Ⅲ部分 如何做到快速、一致、有效第10章 资源加载 22110.1 资源引用策略 22210.2 打包粒度 23810.3 按需加载 24110.4 本章小结 242第11章 至关重要的性能 24311.1 高性能架构设计 24411.2 精简并复用vendor库 25111.3 本章小结 272第12章 UI设计系统 27512.1 为什么需要一个设计系统 27612.2 公用设计系统与自治团队 27912.3 运行时整合与构建时整合 28612.4 样式库中的组件通用与定制 29312.5 哪些组件应该沉淀到中心化的样式库中 29812.6 本章小结 303第13章 团队及职责边界 30513.1 将系统与团队对齐 30613.2 知识分享 31413.3 横向共性问题 31713.4 技术多样性 31913.5 本章小结 323第14章 迁移、本地开发及测试 32514.1 迁移 32614.2 本地开发 33314.3 测试 33914.4 本章小结 341前言/序言
我是一名有着20年经验的Web开发人员。在这20年中我参与了各种规模的项目其中包括独自一人开发的微型创业项目与其他几位同伴一同完成的小型项目也参与过多人合作的大型项目(人数肯定超过了我家餐桌旁摆放的椅子数量)。
2014年我和neuland Büro für Informatik的同事们负责为一家连锁百货公司重建电子商务系统。其现有的电子商务系统不仅存在性能问题而且结构非常混乱在其基础上开发新的功能需要耗费很长时间通常还会引发系统其他功能的故障。随着相关开发团队规模的逐渐扩大系统愈发难以维护。客户要求新的系统除了具有更加合理的架构外还希望在此架构上不同的开发团队能够独立开展工作互不影响。这种并行开发的能力对于客户以信息化为基础快速扩张业务的计划有着至关重要的意义。为此我们选择了一种“垂直化”的系统架构按照职能划分设立多个独立的团队每个团队专门负责一块特定业务的开发包括从数据库到前端页面展示的所有工作。这样每个团队所负责开发的部分都是独立和自治的最终会在前端页面层面整合在一起。从概念上来看前端整合似乎没有什么难度但事实上我们需要掌握大量的知识才能有效地实现前端整合。随着项目的深入我们逐步完善了所采用的技术并从实践中总结了大量经验。
与此同时其他公司也在采用类似的技术方案。然而业界对这种方案没有一个统一的命名。每当我想通过搜索引擎了解多个独立且自治的团队在共同完成一个Web应用程序所面临的挑战时总是无法找到合适的搜索词来恰当地描述我的意图。在2016年11月ThoughtWorks Technology Radar将这种技术方案命名为“微前端”这一术语的出现更加便于大家在开发社区中围绕一致的技术架构分享最佳实践、技术和工具。
在2017年的夏天我抽空对实践中的一些经验进行了总结。将所使用的技术凝结为独立的示例项目并发布到https://micro-frontends.org上。从那时起情况发生了一些变化我被邀请在各种会议上发言也收到了许多杂志社的约稿。社区中的开发人员还将网站翻译成各种语言。
最重要的是去年年初Manning出版社的Nicole和Brian找到了我。他们邀请我写一本关于微前端的书。收到邀请时我首先想到的是“这有点离谱我可不是一名作家我甚至不喜欢阅读文字而更喜欢倾听、编写代码、搭建系统以及解决问题”。但这看起来又是一个千载难逢的机会在给出答复之前我经过了慎重考虑并与家人和朋友讨论了多次。最后我决定抓住机会接受这个邀请。毕竟我非常喜欢表达和阐述。将思考总结成书以图(我非常喜欢图)和代码示例的方式呈现对我来说也是一种挑战在整个过程中我也能学到很多东西。回顾编写本书的历程我很满意当初的决定以及这个决定的最终产物也就是各位现在看到的这本书。
