第 4 章 客户端渲染微前端 客户端渲染微前端
本作品已使用人工智能进行翻译。欢迎您提供反馈和意见:translation-feedback@oreilly.com
在本章中,我们将使用微前端决策框架,使用模块联盟(Module Federation)构建一个基本的电子商务网站,采用客户端渲染方法。正如我们已经讨论过的,在架构方面没有放之四海而皆准的解决方案。当我们需要选择一种方法时,项目的目标、组织结构和沟通方式以及公司现有的技术能力都是我们必须考虑的因素。
在确定了我们的操作环境后,我们可以使用微观前端决策框架来帮助确定架构技术方向的关键支柱。我不会在多个框架中创建相同的示例,而是专注于帮助你建立正确的心智模型,这将使你能够掌握任何微前端框架,而不是只记住一两个可用的选项。
我们肯定会探索一些代码,但我会强调理解决策原因的重要性。这样,无论你在下一个项目中使用哪种方法和框架,你都能决定正确的方向,而与你对特定微前端框架的熟悉程度无关。
还记得 "授人以鱼,不如授人以渔 "这句老话吗?让我们一起来学习钓鱼吧。
项目
我们的项目是一个内部 T 恤电子商务网站,用于一个企业组织。网站由多个子领域组成:
-
主页
-
登录
-
付款
-
目录
-
账户管理
-
员工支持
-
常见问题
在本章的示例中,我们只使用其中的几个子领域:主页、身份验证、目录和账户管理。电子商务网站必须具有一致的用户界面,这样用户在选购自己喜欢的 T 恤衫时才能获得一致的体验。我们将有几个团队负责完成这个项目。为了按期完成项目,技术部门决定重新使用为 B2C 电子商务解决方案开发的内部引擎。这是一个单体后端架构,经过数年的开发和生产环境中的加固,已经过实战检验。然而,技术部门希望摆脱前端和后端专业知识各自为政的局面,因此决定使用微前端,成立独立团队负责新电子商务网站的子领域。它还将利用后端开发人员,使用微服务重新架构后端,并在业务和技术层面融入 Agile。
下一步是分配负责不同子领域的团队:
-
Sashimi 团队将负责主页子领域。由于这是一个内部电子商务网站,该团队将使用现有的集中认证系统实施登录表单,员工使用该系统访问组织内部的每个系统。该团队还将负责 "账户详细信息 "微前端的用户验证和个人信息收集。一名团队成员将负责全栈开发,其余成员将专注于与微软活动目录(AD)的后台集成。
-
Maki 团队将负责核心域--目录。这是最大的团队,将负责主要的用户体验。该团队将由前台和后台开发人员组成。
-
Nigiri 团队将负责支付子领域。它将整合不同的支付方式,如信用卡和 PayPal。
我们要实施的流程由三个部分组成。图 4-1显示,用户首先看到的是主页,然后通过验证才能看到完整的目录。目录微前端将是一个垂直分割的微前端,而 "我的账户 "部分将由两个 水平分割的微前端组成。 我们可以只让一名开发人员负责身份验证前端,因为较重的实施部分在后台。但对于目录,我们希望获得更丰富的用户体验,因此我们需要一个对前端实践有深入了解的团队。 最后,由于账户管理是不同子领域的交叉点,负责这些子领域的两个团队将帮助开发这一视图。
图 4-1. T 恤衫电子商务部分:主页、登录、包含产品详细信息的目录和账户管理
按照微前端决策框架,并通过概念验证来测试他们的假设,这两个团队决定使用以下方法: ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access