前后分离的总结

前后分离的总结

我们遇到了什么问题?

1.前端无法调试后端未完成的 API:如果后端同学还没有完成 API 开发,那么前端同学就不能对这个 API 进行开发。之前我们都是在代码里直接通过给变量赋假数据,又或者是在后端 Controller 里直接 return JSON 的方式来进行调试的。这样的方式很容易会出现的情况就是,每次提交 commit 都要把它删除掉,有时忘了没有删除掉,那么提交历史就会变得很脏。

2.没有自动化测试:前端对接口的调用没有做自动化的测试。

3.前端需要依赖后端开发环境:前端需要后端环境来在本地测试,像我们使用的方案就是 Vagrant + 虚拟机的来开发。这样的方式其实很笨重,不但每次启动虚拟机都得等一段时间,而且会占用一定的 CPU 和内存资源,拖慢机器。然而,前端需要的只是数据。

如何去解决这些问题? ——前后端分离

大部分的互联网公司都分成了前端团队和后端团队。在软件设计中,我们有一个思想就是 Separation of Concerns (Soc),也就是 关注点分离 的思想。既然我们采用了前后端由不同团队开发的模式,那么我们应该有分治的思想,也就是说,我们要尽可能更多地关注自己从事的领域。

一.为什么要前后端分离?

1.框架层面

前后端仓库的分离:

整个前端工程使用git subtree从后端Git工程中切分出来。后端应用均使用同一个前端代码库。

前端只clone前端代码,启动前端工程。前端使用sever来mock数据渲染ftl模板以及页面展示

2.开发层面

前后端约定好接口,各自开发;节约时间(但联调的时间可能增加),接口有更新及时沟通

前后分离的总结

上线可以只上前端或后端代码

二.如何实现前后端分离

怎么做前后端分离,我们认为的前后端分离

前端:负责View和Controller层。

后端:负责Model层,业务处理/数据处理等。

前后分离的总结

试想一下,如果前端掌握了Controller,我们可以做url design,我们可以根据场景决定在服务端同步渲染,还是根据view层数据输出json数据,我们还可以根据表现层需求很容易的做 Bigpipe,Comet,Socket等等,完全是需求决定使用方式。

实际上,现在很多的成熟的网站都没有做到上面的设计,很多时候后端也负责一部分View的渲染,例如很多的后端模版,有的时候这是很需要的。所以我们现在所谈的前后端分离,更多的是基于上面我们所遇到的问题出发,即基于现有的前后端共同渲染View,但前端又能独立开发的优化角度出发。

方案一:采用 SPA 架构

业界很多公司会采用 SPA(Single Page Application,单页应用)的架构,这种架构是天然的前后端分离的。所有的数据都是后端通过 JSON 的形式来传递到前端,前端本身也有自己的 MV* 框架,从物理上实现了前后端分离。

WEB服务中,SPA类占的比例很少。很多场景下还有同步/同步+异步混合的模式,SPA不能作为一种通用的解决方案。

方案二:淘宝 UED 的大前端方案(中途岛)

前后分离的总结
上图是淘宝基于Node的前后端分离分层,以及Node的职责范围。简单解释下:

-最上端是服务端,就是我们常说的后端。后端对于我们来说,就是一个接口的集合,服务端提供各种各样的接口供我们使用。因为有Node层,也不用局限是什么形式的服务。对于后端开发来说,他们只用关心业务代码的接口实现。
-服务端下面是Node应用。
-Node应用中有一层Model Proxy与服务端进行通讯。这一层主要目前是抹平我们对不同接口的调用方式,封装一些view层需要的Model。
-Node层还能轻松实现原来vmcommon,tms(引用淘宝内容管理系统)等需求。
-Node层要使用什么框架由开发者自己决定。不过推荐使用express+xTemplate的组合,xTemplate能做到前后端公用。
-怎么用Node大家自己决定,但是令人兴奋的是,我们终于可以使用Node轻松实现我们想要的输出方式:JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/同步、异步,想怎么整就怎么整,完全根据你的场景决定。
-浏览器层在我们这个架构中没有变化,也不希望因为引入Node改变你以前在浏览器中开发的认知。
-引入Node,只是把本该就前端控制的部分交由前端掌控。

淘宝 UED 的大前端方案的思想是非常先进的,在前端 HTML/CSS/JS 和后端 Java 之间,架设了一层 NodeJS,把 View 层和 Controller 层都交由前端团队去开发,后端团队只负责 Modal 层。然而,这种方案对项目的改动将非常大,改造成本非常高。做到了真正的前后端分离。这并不是我们所要谈论的。有兴趣的可以搜索下相关的文章。

方案三:构建 Mock Server

Mock Server 的概念非常简单,就是在开发环境构建一个模拟的服务器,然后构建假数据(Mock Data),再利用构建的假数据来进行开发。

这种方法的好处:

灵活性高:它小到可以只拦截一个 HTTP 请求,对某一个 API 进行调试;大到前端可以完全使用 Mock Server 进行开发,在本地完全不需要跑后端服务器。所以它可以以非常平滑柔和的方式融入到前端项目的开发当中。
构建简单:我们甚至只需要通过 Fiddler 或者 Charles 等抓包拦截软件,就可以完成一个 Mock Server 的构建。
能自动生成 API:由于数据和接口都是确定的,所以我们可以利用它来创建 API 文档,便于前后端开发。
能为自动化测试铺路:同样是由于数据和接口都是确定的,所以我们还可以利用它来做单元测试。

三.如何对我们的项目进行改造?

前后分离的总结

四.具体的实现

我们想要的Mock数据的样子:

1.全工程的数据都要Mock;
2.在固定平台上创建接口,接口的请求参数和返回参数灵活配置;
3.能通过简单的命令实现数据的Mock;
4.只启动前端工程,不启动后端工程;

网上有很多的开源技术,可以实现Mock数据的功能;

1.sosoapi

前后分离的总结

2.taobo rap的项目,RAP

前后分离的总结

上面开源技术的优缺点:

特点:友好的图形界面,完整的接口文档

缺点:接口完全托管在网站上,安全隐患

简单的数据伪造,只实现本地的数据伪造(无接口文档)

1.Mock.js

使用参考

前后分离的总结

2.faker.js

API参考

前后分离的总结

特点:安全性高,产生本地数据;根据语法产生对应的数据

缺点:无图形界面,手动编写接口文档

很多时候,我们写单页面应用时,都需要启动一个本地sever,这里推荐puer。简而言之,Puer是一个可以实时编辑刷新的前端服务器;同时它还兼有模拟数据的功能。

文档型

apiary

前后分离的总结

swagger editor

特点:优美的接口文档

缺点:无图形界面,编写文档学习成本高;适合后端编写接口文档


总结:
如果要做工程性的,要建立起我们开始介绍固定站点,图形化录入和展示接口;并建立起和工程结合的mock数据功能。
如果我们只是开发单页面应用,可以使用Mock.js来模拟单一化的数据。
如果要写接口文档,建议使用apiary。
简单的先做以上的介绍。

[参考]:

https://www.zhihu.com/question/35436669

上一篇:C#委托与事件学习笔记


下一篇:visualstudio2019 的报表技术rdlc在windows10上出现乱码的问题解决方法