前端有架构吗?前端有架构模式吗?
架构是什么?
软件架构,是一种为了解决复杂问题的通用模式。软件架构,是关于软件系统的一系列有层次的技术决策的集合。换句话来说,当我们讨论架构的时候,不能只讨论某某架构,而是要包含其实施,以及后期的维护。
因为:
一个无法上线的应用架构,算不上是好的软件架构
一个没有人能完成开发的软件架构,算不上是可行的软件架构
一个在现有的技术上不可行的架构,算不上是合理的软件架构
诸如微服务,对于复杂的后端系统来说,是一种不错的『低耦合,高内聚』的实施。但是,它并不适合于大部分的小公司——复杂的架构不适合于简单的应用。而小公司也缺乏足够的人才,来实施一个复杂的系统,与此同时还需要有人能维护这个系统。
所以,当我们谈及软件架构的时候,说的是:有这么一些人,他/她们能按时、高质量(或者说有质量)完成这一个系统的设计——即有能力的个人。
PS:对于前端架构来说,这些人大概率会来自于看了本书的人,笑~
前端架构拆解:四层次设计
从笔者的角度来看,架构设计本身是分层级的,面向不同级别的人时,所展示的内容也是不一样的。如面对的是同一级别、更高一级别的架构师、技术人员,说的便是形而上学的东西,如微前端、前后端分离,并通过各种概念,如构建系统拆份,以抽象的方式介绍如何去设计。这些概念,对于接触过的程序员来说,也是相当好理解的。而当我们面对的是,经验略微丰富的程序员的时候,说的可就不是:去实现微前端这样的东西。而是需要落实到怎样去做这样的一件事。
在不同的时期,不同的阶段,我们考虑的架构相关的因素是不同的。按照这个思想,笔者将架构的设计分为了四个层级:
系统级,即应用在整个系统内的关系,如与后台服务如何通讯,与第三方系统如何集成。应用级,即应用外部的整体架构,如多个应用之间如何共享组件、如何通信等。模块级,即应用内部的模块架构,如代码的模块化、数据和状态的管理等。代码级,即从基础设施来保障架构实施。
对应的层级与实施模式,如下图所示:
!前端四个层级
系统内架构
在设计前端架构的时候,首先考虑的是应用在整个系统中的位置——它与系统中的其它子系统是怎样的。这种关系包含了架构上的关系、业务上的关系,以及它们之间的协作机制。对于前端应用来说,这一部分的子系统包含了:
其它前端应用。侧重于关注如何与这些应用交互,诸如交互、通讯等。
对接的后台服务。关注于如何与后台服务进行通信,诸如权限、授权、API 管理等。
若是系统间的数据通信,如与后台服务之间的交互,那么只需要规定好数据通信、数据传递的机制即可。这一类的通讯机制,不仅仅包含了前后端分离架构的 API 设计,还包含了各类的数据传递,诸如 OAuth 跳转的 Token 验证。除此,对于传统的多页面应用来说,也需要关注于其中的数据传递,如 Cookie 作为用户凭据等等。
为此,对于前端开发人员来说,关于与后端间的关系,我们所要考虑的主要因素是前后端分离架构的设计。
前后端分离架构。(详见《前端架构:从入门到微前端》)
微前端架构。(详见《前端架构:从入门到微前端》)
而后,我们还需要考虑到前端的客户端展现形式。在大前端的背景之下,它可能是以 PC Web 应用、移动 Web 应用、混合移动应用(结合 Cordova 构架)、混合桌面应用(结合 Electron 框架)、原生移动应用(结合 React Native)等,具体选择何一种技术,取决于我们在之前调查的利益相关者的需求。
当我们做完上述的三个核心的架构决策之后,就需要考虑一下应用的部署架构。不同的客户端形式,或者需要服务端渲染,会在某种程度上影响到前端应用的部署,但是总的影响并不是太大。往往只需要通过反向代理的配置,就可以完成部署的配置。若是与后台服务不在一个域,则需要考虑支持跨域请求或者是后台做一层代码。
在有了这些基本的架构设定,便可以往下继续设计下一层级的应用架构。
应用级架构
应用级架构,指的是单个应用与外部应用的关系,如微服务架构下的多个应用的协作。它可以是一个团队下的多个前端应用,又或者是一个组织内的前端应用。其在组织中所处的位置,也进一步决定了我们所需要设计的架构方案。
若是从相关的定义上来看,它与系统级应用存在一定的交集。但是,笔者将其视之为系统级架构的进一步细化。如在系统内架构的层级里,我们定义了微前端架构,而具体的实施细则会放在各个应用中实现的。而诸如应用间的数据如何交换,而不同的应用又有各自不同的实现,则会在这个层级里定义了相应的接口。
与此同时,当我们维护了多个前端应用,必然会去考虑在这些应用之间,复用代码、共享组件库、统一设计等,以减少相应的工作量。为此,在这个层级里,我们会考虑下面的一些架构相关的设计内容:
脚手架。(详见《前端架构:从入门到微前端》)
模式库。(详见《前端架构:从入门到微前端》)
设计系统。(详见《前端架构:从入门到微前端》)
与此同时,在这个层级里,我们决定选择什么前端框架,进行相关的技术选型。
模块级架构
模块级架构,便是深入单个应用内部,更细致的设计应用内部的架构。它所涉及的部分,便是在日常开发中,我们经常接触到的主要部分。我们所做的便是制定一些规范,又或者是更细致的架构设计。这部分的内容,会在我们开始业务编码之前进行设计,在敏捷软件开发中,它称之为 迭代 0/Sprint 0/Iteration 0。相关的内容有:
模块化。(详见《前端架构:从入门到微前端》)
组件化。(详见《前端架构:从入门到微前端》)
除此,对于不同的框架,还涉及到一些框架特定的模式与架构设计,它们会在一定程度上影响单个应用的架构。对于不同的框架来说,所需要涉及的范围都有所不发。如在 Angular 框架中,不需要操心相关的模式,只需要掌握框架定义的规范即可,如使用 Service 来保存应用的状态,使用 Pipe 来处理数据等。而在 React 框架中,则需要设计状态和数据流的管理方式,为此便需要诸如 Flux 或者 Redux 这样的状态管理方案。
代码级:规范与原则
当我们真正编码的时候,考虑的架构因素便是更低层级的内容。这部分的架构设计,便称为代码级的架构设计,它关注于实践过程中的相关规范和原则。这部分的内容相当的多,并且繁琐。它包含了以下的内容,但是又不限于下述的部分:
开发流程。(详见《前端架构:从入门到微前端》)
代码质量及改善。(详见《前端架构:从入门到微前端》)
规范而非默契。(详见《前端架构:从入门到微前端》)
除此,在日常的开发中,还需要注重代码的可维护——简单的代码更容易读性和维护。笔者维护一个 Scala 项目的过程中,便是深有体会——越是写得越抽象的代码,越难以维护。诸如函数式编程是一个好的东西,但是好的东西也容易被烂用,导致人们不喜欢这个东西。