前端有架构吗?前端有架构模式吗?
什么是架构?
软件架构是解决复杂问题的通用模式。软件架构是关于软件系统的分层技术决策的集合。换句话说,当我们讨论架构时,我们不应该只讨论某个架构,还应该包括它的实现和后期维护。
因为:
一个无法上线的应用架构,算不上是好的软件架构一个没有人能完成开发的软件架构,算不上是可行的软件架构一个在现有的技术上不可行的架构,算不上是合理的软件架构例如,对于复杂的后端系统,微服务是“低耦合、高内聚”的良好实现。但是,它不适合大多数小公司——复杂的体系结构不适合简单的应用。小公司也缺乏足够的人才来实施一个复杂的系统,同时需要有人来维护这个系统。
所以,当我们谈到软件架构的时候,我们说有一部分人能够按时、高质量地完成这个系统的设计——也就是有能力的个人。
PS:对于前端架构,这些人的概率会来自于看过这本书的人,笑~
前端架构的反汇编:四层设计
从作者的角度来看,建筑设计本身是有层次的,面对不同层次的人,展示的内容是不同的。如果你面对的是同层次、更高层次的建筑师和技术人员,你说的是形而上的东西,比如微前端、前端分离,通过建筑系统拆卸等各种概念,抽象地介绍如何设计。这些概念对于接触过的程序员来说是相当容易理解的。当我们面对经验略丰富的程序员时,我们说的不是:实现微前端。但是怎么做这样的事情。
在不同的时期和阶段,我们考虑与建筑相关的不同因素。根据这一思想,作者将建筑设计分为四个层次:
系统级,即整个系统中应用之间的关系,比如如何与后台服务进行通信,如何与第三方系统进行集成。应用级,即应用外部的整体架构,比如如何共享组件,多个应用之间如何通信。模块级是应用的内部模块架构,如代码模块化、数据和状态管理等。代码级,即从基础设施上保证架构的实现。
相应的级别和实现方式如下图所示:
!前端四层
系统内架构
在设计前端架构时,首先考虑的是应用程序在整个系统中的位置——它与系统中的其他子系统相比如何。这种关系包括架构关系、业务关系以及它们之间的合作机制。对于前端应用,子系统的这一部分包括:
其它前端应用。侧重于关注如何与这些应用交互,诸如交互、通讯等。对接的后台服务。关注于如何与后台服务进行通信,诸如权限、授权、API 管理等。在系统之间进行数据通信的情况下,比如与后台服务的交互,只需要指定数据通信和数据传输的机制。这种通信机制不仅包括前端分离架构的API设计,还包括各种数据传输,比如OAuth跳转的Token验证。此外,对于传统的多页面应用,我们还需要注意数据传输,比如Cookie作为用户凭据等等。
因此,对于前端开发人员来说,考虑与后端关系的主要因素是前端分离架构的设计。
前后端分离架构。(详见《前端架构:从入门到微前端》)微前端架构。(详见《前端架构:从入门到微前端》)然后,我们还需要考虑前端客户端呈现形式。大前端背景下,可能是PC Web应用、移动Web应用、混合移动应用(结合科尔多瓦框架)、混合桌面应用(结合电子框架)、原生移动应用(结合React Native)等。选择哪种技术取决于我们之前调查的利益相关者的需求。
在我们做出以上三个核心架构决策之后,我们需要考虑应用部署架构。不同的客户端形式或者服务器端渲染都会在一定程度上影响前端应用的部署,但总体影响不会太大。通常只需要配置反向代理来完成部署配置。如果和后台服务不在同一个域,那么就需要考虑支持跨域请求或者在后台做一层代码。
有了这些基本的体系结构设置,您就可以继续设计下一级的应用程序体系结构。
应用层架构
应用级架构是指单个应用与外部应用之间的关系,比如微服务架构下多个应用的协作。它可以是一个团队下的多个前端应用程序,也可以是组织内的前端应用程序。它在组织中的地位进一步决定了我们需要设计的架构方案。
从相关定义来看,与系统级应用有一定的交集。然而,作者认为它是系统级体系结构的进一步细化。比如在系统架构的层次上,我们定义了微前端架构,具体的实现细节会在各种应用中实现。比如应用之间如何交换数据,不同的应用有不同的实现,相应的接口会在这个层次定义。
同时,我们在维护多个前端应用的时候,必然会考虑重用代码,共享组件库,统一这些应用之间的设计,以减少相应的工作量。因此,在这个层面上,我们将考虑以下架构相关的设计内容:
脚手架。(详见《前端架构:从入门到微前端》)模式库。(详见《前端架构:从入门到微前端》)设计系统。(详见《前端架构:从入门到微前端》)同时,在这个层面上,我们决定选择什么样的前端框架,选择相关技术。
模块级架构
模块级架构是深入单个应用程序,更详细地设计应用程序的内部架构。它涉及的部分是我们在日常开发中经常接触到的主要部分。我们所做的是制定一些规范,或者设计更详细的架构。这一部分将在我们开始业务编码之前设计。在敏捷软件开发中,称为迭代0/Sprint 0/Iteration 0。相关内容有:
模块化。(详见《前端架构:从入门到微前端》)组件化。(详见《前端架构:从入门到微前端》)另外,对于不同的框架,还会涉及到一些框架特有的模式和架构设计,在一定程度上会影响单个应用的架构。对于不同的框架,需要涵盖的范围各不相同。比如在Angular框架中,不需要担心相关的模式,只需要掌握框架定义的规范,比如使用Service保存应用状态,使用Pipe处理数据。在React框架中,需要设计状态和数据流的管理模式,因此需要一个状态管理方案,如Flux或Redux。
代码级别:规范和原则
当我们真正编码的时候,我们考虑的架构因素是底层内容。架构设计的这一部分称为代码级架构设计,侧重于实践中的相关规范和原则。这一部分的内容相当多,也相当繁琐。它包含以下内容,但不限于以下部分:
开发流程。(详见《前端架构:从入门到微前端》)代码质量及改善。(详见《前端架构:从入门到微前端》)规范而非默契。(详见《前端架构:从入门到微前端》)此外,在日常开发中,有必要注意代码的可维护性——简单的代码更容易阅读和维护。在维护一个Scala项目的过程中,作者有一个很深的体会——代码写得越抽象,维护起来就越困难。比如函数式编程,是个好东西,但是好东西容易用坏,导致人们不喜欢。
总结
买,买,买
——摘自《前端架构:从入门到微前端》
1.《前端框架有哪些 前端架构,有什么能做的?》援引自互联网,旨在传递更多网络信息知识,仅代表作者本人观点,与本网站无关,侵删请联系页脚下方联系方式。
2.《前端框架有哪些 前端架构,有什么能做的?》仅供读者参考,本网站未对该内容进行证实,对其原创性、真实性、完整性、及时性不作任何保证。
3.文章转载时请保留本站内容来源地址,https://www.lu-xu.com/guoji/753867.html