浅谈前后端分离（下篇）

lyb-geek

发布于 2022-03-10 06:14:39

1.2K0

上篇主要介绍一下前后端分离的一些优缺点，本篇主要介绍一下前后端分离的一些落地，不过在介绍之前，要先阐述一下在实施前后端分离时，要考虑到一些东西

前后端分离的误区？

1、前端人员配备是否充足？

采用前后端分离模式可以减后台负担，加快研发效率，当然，前提是前端能做好的话。以往只需要提供静态页面的前端人员，在前后端分离模式中要负责项目的view+controller部分，即除了静态页面，还需要负责页面的所有交互代码、以及nodejs与视图层以及后端API的交互工作，无疑增加了前端人员的学习成本，在没有足够知识和人才储备的情况下，只能让前端人员加班加点。结果是大量前端人员离职（PS：做这么多事，工资总得加吧！）

2、前后端职责分配？

很多公司认为采用前后端分离之后，前后端只需要通过指定API进行交互即可，前端负责页面渲染，Nodejs负责路由分配，后端提供API。忽视了大量关键工作，职责分配和细节处理没有相应文档规定，缓存机制、图片上传下载、数据校验、语言国际化等等并没有出具相应信息。另外，大量忽视了nodejs层的作用，仅仅把nodejs当成一个路由中转，这一方面也是对nodejs技术的不熟悉导致的，其实nodejs能负责很多事，除了复杂业务逻辑处理和数据操作由Java 负责，大量工作完全可以在nodejs层处理。（PS：还是基础不够导致的！）

3、后端API是否Restful风格？

很多公司采用了前后端分离模式后，后端API仍然采用以往的传统风格，这是不合理的，Restful风格的API应该是前后端分离的最佳实践。ResultFul推荐每个URL能操作具体的资源,而且能准确描述服务器对资源的处理动作，通常服务器对资源支持get/post/put/delete/等，用来实现资源的增删改查。前后端分离的话，这些api-url是对接的桥梁，采用resultFul接口地址含义才更清晰、见名知意。（PS：用了Spring4.x 竟然还不用rest风格，说不过去啊）

　4、前后端协作模式？

前后端分离后，无论是API接口的对接还是测试工作，都涉及到前后端人员的沟通，很多公司采用前后端分离后，前后端协作模式配合力度底，互相等待，开发效率低下，反而不如传统的开发模式。例如：当后端 API 没有编写完成时，前端无法进行调试，这就导致了前端会被后端阻塞的情况。其实像这种互相等待的模式需要改进， Mock Server 可能可以解决一些问题。

当我们决定需要前后端分离时，我们仍然还需要面对一系列的问题

是否足够的安全？如果我们设计出来的架构不够安全，那么这一系列的操作都是白搭。我们怎么去存储用户数据，使用 LocalStorage 的话，还要考虑加密。
采用哪种认证方式来让用户登录，并保存相应的状态？
是否有足够的技术来支撑前后端分离？
有没有能力创建出符合 RESTful 风格的 API？
是否有能力维护 API 接口？当前端或者后台需要修改接口时，是否能轻松地修改。
前后端协作的成本高不高？前端和后台两个团队是不是很容易合作？是不是可以轻松地进行联调？前后端职责是否能明确？即：后台提供数据，前端负责显示。
是否建立了前端的错误追踪机制？能否帮助我们快速地定位出问题。

前后端分离如何规划？

　怎么做前后端分离？大方向就是

　后端专注于：后端控制层（Restful API） & 服务层 & 数据访问层；

　前端专注于：前端控制层（Nodejs） & 视图层

　本人认为的前后端分离模式应该是这样，当然这不一定正确：

项目设计阶段，前后端架构负责人将项目整体进行分析，讨论并确定API风格、职责分配、开发协助模式，确定人员配备；设计确定后，前后端人员共同制定开发接口。
项目开发阶段，前后端分离是各自分工，协同敏捷开发，后端提供Restful API，并给出详细文档说明，前端人员进行页面渲染前台的任务是发送API请(GET,PUT,POST,DELETE等)获取数据（json，xml）后渲染页面。
项目测试阶段，API完成之前，前端人员会使用mock server进行模拟测试，后端人员采用junit进行API单元测试，不用互相等待；API完成之后，前后端再对接测试一下就可以了，当然并不是所有的接口都可以提前定义，有一些是在开发过程中进行调整的。
项目部署阶段，利用nginx 做反向代理，即Java + nodejs + nginx 方式进行

如何做到前后端分离

(以下的内容都是基于我们的电影购票网站来讨论的) 前端的技术框架是: vue全家桶+nodejs+express(实现的是单页面(SPA)应用) 首先，先分清楚前后端的工作

前端的工作：实现整一个前端页面以及交互逻辑，以及利用ajax与nodejs服务器（中间层)交互
后端的工作：提供API接口，利用redis来管理session,与数据库交互

我们项目的整一个架构如下:

接下来进入正题，如何实现前后端分离

一般来说，要实现前后端分离，前端就需要开启一个本地的服务器来运行自己的前端代码，以此来模拟真实的线上环境，并且，也是为了更好的开发。因为你在实际开发中，你不可能要求每一个前端都去搭建一个java(php)环境，并且在java环境下开发，这对于前端来说，学习成本太高了。但如果本地没有开启服务器的话，不仅无法模拟线上的环境，而且还面临到了跨域的问题，因为你如果写静态的html页面，直接在文件目录下打开的话，你是无法发出ajax请求的(浏览器跨域的限制),因此，你需要在本地运行一个服务器，可是又不想搭建陌生而庞大的java环境，怎么办法呢？nodejs正好解决了这个问题。在我们项目中，我们利用nodejs的express框架来开启一个本地的服务器，然后利用nodejs的一个http-proxy-middleware插件将客户端发往nodejs的请求转发给真正的服务器，让nodejs作为一个中间层。这样，前端就可以无忧无虑的开发了
由于前后端分离后，前端和后台同时开发时，就可能遇到前端已经开发好一个页面了，可是却等待后台API接口的情况。比如说A是负责前端，B是负责后台，A可能用了一周做好了基本的结构，并且需要API接口联调后，才能继续开发，而此时B却还没有实现好所需要的接口，这种情况，怎么办呢？在我们这个项目里，我们是通过了mock来提供一些假数据，我们先规定好了API接口，设计出了一套API文档，然后我们就可以通过API文档，利用mock(http://mockjs.com)来返回一些假数据，这样就可以模拟发送API到接受响应的整一个过程，因此前端也不需要依赖于后端开发了，可以独立开发，等到后台的API全部设计完之后，就可以比较快速的联调。

为什么要引入nodejs作为中间层

前面的我发的项目结构图中，已经表明，在这个项目里，我们将nodejs作为中间层，那么，为什么我们要特地引入nodejs呢？直接用java做不就行了吗？

我觉得引入nodejs主要是为了分层开发，职责划分，nodejs作为前端服务器，由前端开发人员负责，前端开发人员不需要知道java后台是如何实现的，也不需要知道API接口是如何实现的，我们只需要关心我们前端的开发工作，并且管理好nodejs前端服务器，而后台开发人员也不需要考虑如何前端是如何部署的，他只需要做好自己擅长的部分，提供好API接口就可以；
nodejs本身有着独特的异步、非阻塞I/O的特点，这也就意味着他特别适合I/O密集型操作，在处理并发量比较大的请求上能力比较强，因此，利用它来充当前端服务器，向客户端提供静态文件以及响应客户端的请求，我觉得这是一个很不错的选择。