(1). 系统架构:
①. 应用场景:
a. 应用在整个系统内,如与后台服务如何通信,与第三方系统如何集成.
②. 前提条件:
a. 了解前端系统与其它系统间的关系,包括业务关系和协作机制.
b. 了解后端系统,需要规定与后台数据传递的机制,包括:
(1). api设计规范
(2). 访问授权的一个开放标准(OAuth)跳转token的验证
(3). 数据传递cookie等.
c. 了解前后端关系,如前后端分离的架构设计
③. 前后端分离的架构设计:
a. 指的是如何实施技术决策.
b. 包括:
(1). 用户鉴权
(2). API接口管理和设计、API文档管理
(3). Mock的使用
(4). BFF(服务于前端的后端、node.js)
(5). 是否需要服务端渲染
(6). 应用间的分层
(7). 软件的性能优化
(8). 代码的拆分
(9). 项目的管理等
(2). 应用级架构:
①. 应用场景:
a. 应用级架构可以看作系统级架构的细化.
b. 单个应用与其它外部应用的关系,微服务架构下多个应用的协作、数据交换等:
(1). 比如一个微前端子应用与其它子应用的交互
(2). 或者单一的子应用与主应用数据交换
②. 应用级架构设计的形式:
a. 应用间的脚手架:用于整体应用、项目的生成
b. 模式库:Utils方法库、UI库
c. 设计系统:整体应用级架构内部的功能实现、与外部的信息交互等
(3). 模块级架构:
①. 应用场景:
a. 开始业务编码之前进行的设计,称为迭代过程
(4). 代码级架构:
①. 规范与原则:
a. 规范:
(1). eslint、stylelint、htmllint
b. 软件的设计原则、设计模式
②. 开发流程
③. 代码质量:
a. 代码可维护性、可扩展性
b. 简单代码可维护性高,越是抽象代码越难以维护
①. 定位:
a. 应用级架构方案:
(1). 在一个系统内微前端是应用间的架构方案
(2). 微前端整体的子应用是应用在一个系统之间
b. 系统级架构方案:
(1). 对于整体的应用而言,在多个应用之间,微前端是一种系统间等架构方案
(2). 微前端负责的是调度所有的子应用,不管是每个子应用的渲染、数据依赖的更新和获取、子应用的激活与卸载
c. 总结:
(1). 微前端是将多个前端应用以某种形式结合在一起进行应用
②. 应用场景:
a. 旨在解决单体应用在一个相对长的时间跨度下
b. 由于参与的人员、团队的增多、变迁,从一个普通应用演变成一个巨石应用(Frontend Monolith)
c. 随之而来的应用不可维护、不利于扩展的问题
d. 解决方案:
(1). 可以使用微前端将一个巨石应用拆解成颗粒度细的应用来进行维护