十年老树发新芽-前后端分离实践

栏目: jQuery · 发布时间: 6年前

内容简介:最早从Web2.0 Ajax技术开始兴起,就有提前后端分离了。从Gmail的单页应用,到现在的单页应用层出不穷。浏览器渲染引擎也一直在突破,越来越多的交互、计算放在了浏览器这一层。传统后端MVC架构,变成了前后端的MVC。后台的接口变成了模型层,逻辑处理层从CGI变成了JavaScript,展示层则还是标记语言HTML和CSS。当前项目从立项到2018年,已经有10余年的历史了。前端的技术栈是jQuery。后台是基于10年前的PHP框架,中间也经历过多次重构。但总体架构还是LNMP,PHP渲染的,存在的问

最早从Web2.0 Ajax技术开始兴起,就有提前后端分离了。从Gmail的单页应用,到现在的单页应用层出不穷。浏览器渲染引擎也一直在突破,越来越多的交互、计算放在了浏览器这一层。传统后端MVC架构,变成了前后端的MVC。后台的接口变成了模型层,逻辑处理层从CGI变成了JavaScript,展示层则还是标记语言HTML和CSS。

为什么要做前后端分离

当前项目从立项到2018年,已经有10余年的历史了。前端的技术栈是jQuery。后台是基于10年前的 PHP 框架,中间也经历过多次重构。但总体架构还是LNMP,PHP渲染的,存在的问题比较多。

  • 从维护侧看:1)业务逻辑复杂,充斥着很多明眼不可见的业务。导致更改bug很容易引发其他的bug。2)代码巨长无比,可读性差。3)代码结构性差、分层模糊,逻辑层的代码充斥在View层中。找代码的时间占据解决bug的大部分时间。4)前端尚处在刀耕火种的年代,前端规范差、压缩混淆不彻底,难以适应新的浏览器渲染技术。

  • 从性能侧看:单一请求,往往读取比页面所需要多得多的数据。频繁的拉取数据,不仅对后端资源是一种浪费,也会导致单一请求耗时过长。

  • 从用户侧看:因为多页应用的频繁刷新,新的URL都需要页面重载。单一页面会触发多个HTTP请求(静态资源、Ajax)。这两个因素导致用户等待时间过久。

  • 从开发人员侧看:1)开发者往往热衷于新技术。学习新技术不仅有利于团队技术成长,也有利于发挥成员的积极性。2)团队成员本身具有全栈开发的能力,转换成前后端分离的模式成本较低。

  • 从业务本身来看:产品天生适合采用单页应用,无需SEO。

前端方案选型

基于上述原因,促成团队下定决心进行正式的改造。新的项目,由于没有历史包袱,采用开源框架是水到渠成的。但对于已有项目而言,采用新框架意味着要对现有代码进行彻底重构。结合自身业务来讲,自研框架可以完美的兼容现有的前端组件库。其次,自研对框架细节的把握程度也会更强。

但是从长期来看,自研意味着需要专业人员长期维护。采用自研,对团队而言是摸着石头过河。我们需要改造业务,需要兼容现有组件,需要考虑长期的维护性,需要考虑安全和性能,需要考虑前端开发流程,还有新成员的上手程度。最重要的还有改造进度和成本。

在前端方案的落地中,团队花费了很长时间进行框架的预研,最终选择了Vue。对业务而言,框架需要提供双向数据绑定、模版引擎、组件化、前端路由,还有能与jQuery组件进行通信,定制化程度较高。

  1. React意味着全局替换,替换成本过高,成果成型慢
  2. Jsx、Ts对偏后台同学而言,学习门槛较高
  3. 在国内Vue显然更受欢迎,文档、社区也更活跃
  4. React许可协议的具有潜在的不可控性

实际开发遇到的问题

1.与jQuery组件通信:庞大的现有组件,短时间内非常难Vue化改造。必须采用hack的方式完成jQuery组件和Vue业务的通信。最终是选择发布订阅模式,收集组件的变更。如果Vue需要知道jQuery组件的变更,jQuery组件需要显式$emit通知到Vue。

2.状态管理:状态管理的加入,会增加开发门槛,使用不恰当也会导致乱用。但如果后续引入,又会增加回炉再造的成本。其次不引入状态管理,全局变量的处理也是问题。

3.样式的规范管理:前端的样式规范,也是需要改造的痛点。最终选用业界使用较成熟的BEM规范。

后端方案选型

这些年后端的发展与前端相比,就显得小巫见大巫了。后端现有代码量更大,如果仅仅为了PHP的命名空间、自动加载、依赖注入,就去更换框架就有些得不偿失了。现有的框架性能、类的加载、路由、关系对象映射模型,已经有较好的方案来支撑。

前后端分离对后端而言,最大的改造点,在于接入层的处理,即数据的输入输出方式。对接口而言,性能对前后端分离的体验至关重要,也是我们重点考虑的问题,我们加入了HTTP协议层的缓存。在代码规范、log管理、安全校验(参数过滤)、业务安全(越权)、频率限制、签名验证、登陆验证等问题,也在框架层面做了完善和加强。最后基于前后端分离流程的完善,我们使用Apidoc作为接口文档的管理工具。

后续的工作

前端

  1. 开发规范:Js代码规范、CSS规范、组件规范,自动检测 工具 支撑。
  2. 代码结构:文件结构划分。
  3. 测试支撑:UI自动化测试、前端构建测试。
  4. 运维监控:前端日志上报、前端错误监控、优化分析。
  5. 运营支撑:点击流、访问转化分析。
  6. 开发调试:开发调试工具的完善。
  7. 运维部署:灰度引入、前端发布流程及工具完善。

后端

  1. 业务接口性能和安全:随着业务改造,新接口的性能及伴随的业务安全。
  2. 共用逻辑的拆分和复用:和现有模式的代码复用和拆分,服务层的完善。

一些观点

  1. 没有工具支撑的规范,抵不过人的惰性。
  2. 动态优化的方法论。改造之前想想两年后你期望项目长什么样,反过来推导现在应该怎么做。
  3. 理解业务是重点,任何框架都会被时代抛弃,选择最适合业务的。
  4. 系统性思维,无论前端还是后端,都具等同性。
  • 开发流程始终围绕:代码管理、开发调试、代码编译、项目构建、模块管理、配置部署、测试支撑、性能检测、安全扫描、规范约束、统计分析、运营支撑。
  • 开发指标:可用性、可靠性、可维护性、安全性。

以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

The Definitive Guide to HTML5 WebSocket

The Definitive Guide to HTML5 WebSocket

Vanessa Wang、Frank Salim、Peter Moskovits / Apress / 2013-3 / USD 26.30

The browser is, hands down, the most popular and ubiquitous deployment platform available to us today: virtually every computer, smartphone, tablet, and just about every other form factor imaginable c......一起来看看 《The Definitive Guide to HTML5 WebSocket》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

XML 在线格式化
XML 在线格式化

在线 XML 格式化压缩工具

UNIX 时间戳转换
UNIX 时间戳转换

UNIX 时间戳转换