blog
blog copied to clipboard
架构一个复杂前端系统需要关注哪些点
近几年的前端领域,最感慨的莫过于【变化太快】。各种思想、框架、类库层出不穷,同一个需求点,通常会有多种实现方案,架构选型工作的难度与日俱增。面对每天都在产生的前端领域新词汇,不免感到心累,也难免产生廉颇老矣,尚能饭否的危机感。
无论如何,架构选型和升级的工作仍然要做,在这样的趋势和潮流下,要想对每一种流行概念都了如指掌成本很高,也没有这个必要。反倒是理清前端开发背后的需求至关重要,只要明白了前端开发需求的本质,也就很容易把散落在开源社区里的各种珍珠捡起来,串起来了。
关注点
在若干年前,大部分的web系统架构都是多页面架构,用户点击链接就会完全重新加载页面,这种架构如今在大部分场景中已经过时,所以这篇文章只针对SPA架构的应用。
接下来我会以对一个复杂Web前端系统的架构为例,分析一下都需要关注那些点,每个点上都有哪些考虑。
URL
一个web系统最终都是要通过URL来访问的,在SPA架构下,URL指代的是页面的状态,通过URL的变化来路由到另一种状态。(数据接口URL会在Server API部分介绍)因此,需要关注的点有:
- URL的结构设计成什么样?
- URL的结构设计的粒度到什么程度?
- 如何监听URL的变化并触发不同状态的呈现?
- 使用哪种history?
- browserHistory / hashHistory / memoryHistory / ……
- URL切换前后是否需要执行相关逻辑?
- 哪些组件可以触发URL的变化?应该如何规范导致这一行为的写法?
- URL传递参数应该遵循什么样的规范?如何保障参数的安全性?
Server API
WEB应用数据来源于服务端,针对不同的场景和不同的前后端架构模式,需要解决几个问题:
- 如何针对不同的场景(开发、联调、线上)提供可靠的数据服务?
- 如何定义接口书写规范?
- 接口文档如何进行管理?
- 如何能够优雅地进行前后端联调?
Data
Data主要描述页面上要显示什么信息,Data一般分为两类数据:一类是从后端Server API拉取回来的数据APIData,另一类是标识界面状态的数据State。这两类数据共同决定了界面最终呈现的状态。在实际的开发中,针对Data需要考虑以下几个点:
- 怎么从服务器端拉取数据?
- Ajax / Fetch / JSONP /……
- 异步请求该如何优雅地书写和组织?
- Promise / thunk / co / async / generator function / ……
- 如何保证数据不被随意的篡改?应该定义怎样的数据读写规范?
- 如何对数据进行预处理,从而实现View层渲染时需要的结构?
- 数据该如何传递给View层?
- 数据层是否应该独立管理?还是按照业务和其他角色代码混在一起?
View
View主要描述页面的最终呈现样式。主要关注的点有:
- 采用什么技术来进行页面渲染?
- 模板引擎
- 虚拟dom
- UI组件
- 页面的初始状态如何定义和渲染?
- 页面上的交互如何处理?
- 页面的样式如何定义和使用?
- 如何保证样式只针对当前页面生效?
- 如何更优雅地书写和管理css样式资源?
- less / sass /postcss / css module /……
- 集中管理 / 就近管理 / 混合管理
- 如何提高样式资源的可维护性?
- View如何被创建,如何被销毁,生命周期如何管理?
- View层代码改如何组织?独立还是和其他角色混合?独立的话,如何分拆关联?
- 如何实现页面状态(data、url)改变时View层自动渲染刷新?
Action
Action主要描述用户或者程序对页面做了什么操作,以及操作行为的处理方法,关注点有
- 页面存在哪些可能的交互?
- 如何管理这些行为交互,确保行为变的可以预测、监控?是否所有的交互都需要可预测、监控?边界如何界定?
- 哪些交互是纯粹组件内部的交互?哪些交互会影响其他组件的状态?对交互该如何分类?不同的交互类型应该采用什么样的处理规范?
- 如何组织和书写交互响应逻辑代码?
- 交互最终如何反映到View的更新?
- 交互中如果存在异步请求,改如何组织代码?
Aspect
监控页面行为、搜集数据、统一错误处理、权限校验等需求
- 我的系统中有哪些地方需要嵌入切面逻辑?
- 如何优雅地实现切面?
- 如何保证切面逻辑可以在任何路由场景下都保持可靠?
- 点击链接触发路由切换
- 手动输入url触发路由切换
- api调用触发路由切换
- session失效后如何处理?
AB Test
如何做针新功能进行灰度发布或者权限控制
- 如何获取当前用户的灰度权限?
- 对于同时存在多个灰度策略的场景如何兼顾获取权限的性能和编码体验?
- 如何根据灰度权限来优雅地渲染页面?
组件复用
复杂web系统里组件复用是强需求,关注点在:
- 如何决定组件的拆分粒度?
- 如何定义和界定组件的类型?
- 系统内复用的特定业务组件;
- 系统间复用的通用业务组件;
- 通用的基础组件、工具等
- 不同类型的组件如何组织管理,便于复用?
- 如何基于现有的技术体系制定通用组件的发布、复用规范?
工程化
如何简化开发体验,提高开发效率,解决环境搭建、服务启动、热更新、mock、测试、联调、构建、部署、性能优化等问题。
- 如何快速地搭建项目脚手架?
- 如何实现简单、优雅、团队统一的工程化开发体验?
- 如何简化各种工程化配置?
- 如何实现持续集成和持续构建?
- 选择何种前后端上线部署方案?分离 or 合并?
- 如何针对应用的特点做好极致的性能优化?
- 如何实现优雅的线上、测试环境的代码调试?
- 如何实现优雅、强大的打包构建服务?
结语
前端开发行业折腾来折腾去,其实都是围绕怎么更好地解决这些本质的问题。有些实现可能是针对某几类或者某一类问题,关注点更小的就只解决某几个问题。
比如:
- Webpack主要针对工程化类中的打包构建问题;
- react主要解决view层的问题;
- redux主要解决data、view、action之间数据流转的问题; …… 除了上述关注点以外,对于大的前端团队,通常还会考虑封装的问题。就是通过封装为业务开发者屏蔽很多杂乱、零碎的技术细节,提供简单、统一、好理解的API及开发工具来提高开发生产效率。
很棒~
赞