聊聊前端工程化的实践与未来

转载本文需注明出处:微信公众号EAWorld,违者必究。

目录:

一、前端过去一年的发展

二、工程化是前端实现的核心

三、EOS8前端工程化设计实践分析

四、总结与展望

一、前端过去一年的发展

2017年的前端发生了非常多的事情。快速的技术进步,似乎已经使前端工程师应接不暇,我们来一起看下去年发生了哪些事件:

  • React16发布前夕,React license风波发展到顶峰,多家公司宣布将不在使用react作为其产品的前端框架。网上对Facebook的声讨也达到了顶点。随后Facebook不得不将React license更改为MIT。这件事情极大的影响了React在大家心中的定位,人们纷纷将目光投向Vue。
  • 去年,Angular一口气发布了两个版本,Angular4以及Angular5。这样的变化似乎在意料之中,又在意料之外。根据官方文档说明,从Angular4之后,每年只会发布一个大版本。然而在刚刚进入18年的时候,Angular 6.0.0 Beta版本发布,让前端开发者不得不感慨,前端之路太心酸了。
  • 2017年是Vue飞速发展的一年,除了学习曲线平缓,Api简单易用之外等诸多原因外,离不开React和Angular的种种“不友好”的行为。
  • PWA(渐进式网页应用)越来越被大家所关注,也越来越被应用。也许这个技术并不是我们一直在寻找的使用网页技术完美支持其它客户端的方法,但PWA使用现代的浏览器技术使得访问网页应用的体验和原生移动应用一样。并且在性能上有了大幅度的提升,而且支持离线访问,像推送通知这样原生APP才有的功能也支持了。
  • WebAssembly(wasm)已经开始被所有主流浏览器支持。也许WebAssembly将会开创Web的VR/AR新时代。
  • 2017年Serverless应用持续增热,这是一种新的可以提高性能又减少资源耗费的架构。你的客户端完全从服务器从分离出来,这样就可以只关注应用本身而不是架构。一个常见的实现方法是用AWS API Gateway和AWS Lambda函数作为后台服务。
  • GraphQL日趋火爆,有胜过REST之势。Samer Buna甚至宣传REST已死。GraphQL允许客户端自定义数据,然后一次获取。而REST方案需要维护获取很多无效数据。Github的新版API已被GraphQL重写。

在变化飞快的前端发展中,前端究竟应该如何开发,究竟应该用什么框架,前端代码如何部署,如何进行前后端分离成为人们争论的焦点。

二、工程化是前端实现的核心

在未来,前端工程化成为工程师关注的核心问题。 而工程化的几个重要方面,就是路由的实现方式,组件模块化,构建自动化。

  • 路由实现方式。前后端分离,前端路由显得尤为重要。除了多层级的设置,还要考虑路由实现方式。
  • 由于前端模块化,各个组件各个模块如何相互通信,则尤为重要。必须统一进行管理,否则在多人同时开发,且页面不断增加的情况下,前端代码会越来越难以维护。
  • 开发的过程中,要考虑到部署方式。尽量使用一套能够满足所有部署方案的方法进行开发,减少部署工作量。

1.路由实现方式

最常用的路由分为Hash路由及History路由。

  • Hash路由:(例http://primeton.com/#/login.html)通过改变地址后面的hash来改变浏览器历史记录,Hash部分不会发至服务端,框架本身根据url来生成相应的模块
  • History路由:(例http://primeton.com/login.html)使用HTML5的History API,提供pushState(),replaceState()等方法。路由请求会发至后端服务器。

一般主流做法推荐使用History路由。

使用History路由的好处在于两点,其一是页面url比较美观,其二是可以复用浏览器自身的前进后退特性,但在SPA(单页面应用)情况下支持history模式需要后端的支持。

由于普元微服务治理平台并不希望路由变化时,浏览器发请求到后端,故使用Hash路由。这样做的好处是通过前端控制用户权限,一定程度上方便后期对系统的扩展。这主要跟整体平台架构的设计有关。

2.灵活部署,解决前后端通信

前后端分离模式的开发模式下,通常有两种部署方式来解决与后端进行ajax通信的问题。一种是Nginx作为部署容器,一种在构建工具中将请求转发。

  1. Nginx作为部署方式,需要启动一个Nginx服务,通过配置config文件,将请求转发到不同的地址。
  2. 若以构建工具的方式,则是通过构建工具启动的server自带的proxy将请求转发出去。

接下来详细介绍使用构建工具转发请求的方式。

以Webpack为例,通过proxy,Webpack server会过滤请求,将带有配置的路径的请求,转发到需要转发的服务器。

当代码需要部署在tomcat中时,由于不同项目在Webapp中的前端文件名称可能不同,每当Webapp中的应用更改名称,前端都需要更改ajax的路径,非常麻烦。

有一种方法可以一劳永逸的解决这个问题。使用NPM build之前,在你的package.json文件中,加上homepage变量来写明你的服务的绝对路径。

npm在build的过程中,默认前端代码就在服务的根路径下,想要重写这个路径,可以在package.json中加入上面的homepage,便可重写。若不想设置固定的路径,则可以用下图实例:

三、EOS8前端工程化设计实践分析

以我们的技术团队目前正在研发的EOS8的前端设计为例,讲一讲前端工程化的实践。

EOS8平台的目标是提供一整套微服务应用平台与应用全生命周期管理平台,能够提供企业快速构建数字化需求交付的能力。

EOS8与我们正在研发的另一款产品DevOps都遵循前后端分离、前端模块化的开发方式进行开发。这样做的好处是能够方便多地同事同时进行开发,减少沟通维护成本,同时保证后期的可扩展性。另外,前后端分离,也是微服务系统比较好的实践。

抛开框架之争,结合EOS8的前端设计,来分析从开发到部署的整个生命周期过程,主要从以下三点来考虑:

1)需要根据需求,考虑清楚页面的路由实现方式,同时从功能角度具体分类各个功能模块。

2)由于平台功能的可添加性非常强,故页面设计需要符合模块化设计,方便后期添加新的功能模块,同时在开发的过程中,需要将ui组件公共化,标准化,方便后期开发。

3)前端代码的架构要考虑最终上线的部署方式,同时也要方便开发人员进行开发。

1.模块化开发

首先,前端工程化的第一步,要先划分清楚前端的功能模块。功能模块之间不能耦合。这样的好处是,不同团队可以同时进行开发,最终将各自开发的模块合入即可。模块的开发遵循统一的开发标准。数据可以通过flux来管理。

我们作了如下的模块划分:

  • 平台状态监控。
  • 用户认证,组织机构管理等。
  • 应用节点配置进行更改,并进行灰度发布等。
  • 应用下各个状态的监控。
  • 不同应用进行统一管理的能力。
  • 对应用提供Api Gateway。

2.模块化路由及页面设置

在这里,模块化主要从路由模块化和页面模块化两个方面来设计。

路由模块化,可以解决父子模块嵌套问题,在单向数据流的框架中,这一点尤为重要。同时,通过路由嵌套,规范页面URL,使整个前端路由清晰,具有方便跳转、传参等优势。

页面模块化则可以提高页面组件的复用率,减少重复的代码。

  • 路由模块化:整个平台可以分为6大模块,每个模块分配一个路由地址,通过路由地址找到不同的模块。图中展示的是一级路由地址,如下图所示:
  • 页面模块化:就单个页面而言,页面需要按照组件的方式组成。为了能够减少组件的复杂性,,可以划分为Container Components以及Presentation Components。

1. Container Components主要用于承载各个不同的公共组件,起到一定布局的功能。同时,他负责与服务端进行通信,获取页面所需的数据,传给Presentation Components。

2. Presentation Components主要用于具体的功能组件。它一般不参与数据的交互,只负责展示Container传给他的数据。这样可以达到最大的复用这个组件

如图所示,页面由Header,SideBar,Content三个组件组成,而每个组件,可由多个小的公共组件组成,如下图所示:

3.部署实践

在这里,模块化主要从路由模块化和页面模块化两个方面来设计。

路由模块化,可以解决父子模块嵌套问题,在单向数据流的框架中,这一点尤为重要。同时,通过路由嵌套,规范页面URL,使整个前端路由清晰,具有方便跳转、传参等优势。

页面模块化则可以提高页面组件的复用率,减少重复的代码。

路由模块化:整个平台可以分为6大模块,每个模块分配一个路由地址,通过路由地址找到不同的模块。图中展示的是一级路由地址,如下图所示:

前端部署的方案有两种:

  • 前后端分离方式,通过nginx转到后台。这种方式不需要关注前端文件的路径问题。
  • 混合模式下,前端代码会放到tomcat中,Ajax以及静态资源需要关注路径问题。

图中左侧为前后端分离的简易方案。具体部署时,通过nginx,可以进行负载均衡,同时可以部署多台nginx服务器。如果性能仍旧无法满足,则可以使用LVS+F5/LVS+Nginx等多种方式进行负载均衡。

图中右侧为最传统的部署方式,将前端编译工具打包出来的文件,放入tomcat中即可。

不同应用场景下,负载均衡的方案有很多,要根据实际的应用场景来选择适合自己的方案。这里我们的前端架构,只要在打包时,根据不同的部署方案,将前端文件的路径问题、ajax路径问题解决即可。

四、展望与总结

  • 展望

微前端这个术语,最初来源于ThoughtWorks公司的技术雷达。传统的微服务架构下的前端:

微前端的核心思想如图所示(图片来源于网络)

微前端的理念,是将一个网站当成一个组件的合成体,每个组件由一个独立的团队负责。带来的好处是每一个团队在选择和升级他们的技术栈时,并不需要与其他团队进行统一,同时代码不依赖于共享状态和全局的变量。

这听起来很美好,不过目前微前端大体上还停留在概念的阶段,具体实施起来困难重重,光是框架之间的壁垒,就难以突破。

也许在某天,技术大牛们终将打破技术的壁垒,实现微前端,让我们拭目以待。

  • 总结

通过前端的展望,可以看出来,在未来,框架将不再限制前端架构,不再制约前端开发人员。人们可以根据自己的业务,选择不同的框架,最后将各个业务模块组合起来。人们需要关注的核心,是如何将前端工程化,如何合理的将业务模块化、如何合理的分配路由,如何更快的进行开发等。

无论采用哪种前端框架,前端开发的本质思路是一样的。学习前端,搭建前端项目,不应只关注具体的框架,更多要从前端工程化的角度出发去实现项目。这样才能使前端项目拥有更短的开发周期,更好的用户体验,更绚丽的页面效果。

关于作者:王若林,普元SOA&云计算部门高级前端工程师,曾在Tibco以及海航科技担任前端工程师,参与开发Tibco Api Gateway、海航商店、海航IAM等项目。现主要从事普元EOS微服务管理平台开发设计工作。

原文发布于微信公众号 - EAWorld(eaworld)

原文发表时间:2018-04-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏架构师小秘圈

架构师教你免广告看视频(送书)

关键时刻,第一时间送达! 作者简介:某互联网公司P8级专家攻城狮,曾参与过央视全台网的研发工作。目前正在做车联网项目的云平台的架构设计与研发工作。 原文出处:互...

3437
来自专栏高性能服务器开发

12 经典游戏服务器端架构概述

现代电子游戏,基本上都会使用一定的网络功能。从验证正版,到多人交互等等,都需要架设一些专用的服务器,以及编写在服务器上的程序。因此,游戏服务器端软...

9287
来自专栏假装我会写代码

基于 Composer 的 PHP 模块化开发

2905
来自专栏腾讯移动品质中心TMQ的专栏

【UTP自动化测试平台系列之终章】前端探索之路

UTP自动化测试平台是TMQ的一个联合项目,目的是方便大家更好地开展自动化测试建设工作,减少重复平台建设的成本,提高产品的自动化测试效率。但是随着项目规模与用户...

40911
来自专栏京东技术

JDFlutter | 京东技术中台新一代跨平台开发框架

JDFlutter 是商城共享技术部-多端融合技术部推出的新一代跨平台开发框架,可快速集成至现有 Android/iOS 工程,开发者可借助 JDFlutter...

1.4K4
来自专栏知晓程序

小程序插件审核又没通过?这才是提审的正确姿势

1393
来自专栏腾讯Bugly的专栏

美团大众点评 Hybrid 化建设

导语 上周末,精神哥去参加了好友小青在北京办的T沙龙,探讨移动端热更新相关的话题。Bugly曾为大家介绍过不少腾讯内部的热更新的框架,正好这次看到了美团,去哪儿...

4839
来自专栏大数据和云计算技术

Chronos:数据中心的任务调度器(job scheduler)

大家周二好,不知不觉工作半周了。今天给大家介绍一个扩展性比较强的开源的调度程序,在研究数据中心调度的兄弟可以好好研究下。 1、Chronos来源 C...

4766
来自专栏程序员宝库

看吧,这就是现代化 PHP 该有的样子

这是一篇社区协同翻译的文章,已完成翻译,更多信息请点击 协同翻译介绍 。 讨论请前往:https://laravel-china.org/topics/8690...

4956
来自专栏Java帮帮-微信公众号-技术文章全总结

学Java开发,绝对的福利

学Java开发,看这张图就够了 ? Java学习 深秋的祝福 很多人想转行学习Java但却不知道怎么学,今天你看到这张图,相信你就知道从哪里开始学习Java了...

3237

扫码关注云+社区

领取腾讯云代金券