前后端分离mock工具（前后端分离用什么技术）

本篇文章给大家谈谈前后端分离mock工具，以及前后端分离用什么技术对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享前后端分离mock工具的知识，其中也会对前后端分离用什么技术进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、使用 MockJs — 实现真正的前后端分离
• 2、mockjs 使用简介
• 3、【Mock.js】前端模拟假数据，不用在手拼了
• 4、不懂前后端分离？这篇就够
• 5、前后端分离方案以及技术选型
• 6、mock.js的使用方法

使用 MockJs — 实现真正的前后端分离

前言： 刚刚看了下的后台，发现我技术文章中，阅读留言最多的是关于移动端的文章，甚至还有人付费赞赏或咨询。关于 PC 端的技术文章就显得比较冷清了，唉，废了好大劲写的，没人看。 和我想的一样，移动端才是王道，下次找工作我也搞移动端😂 。

背景： 去年我写了一篇 学习使用 json-server 和 mockjs 的文章，当时没有仔细研究，文章只提到了 MockJs 其中一个 Random 的用法，关于 MockJs 拦截器和另一个很常用的 Mock.mock 函数都没有提及。这次来搞一下。

唉！以前我也是经常会听到 前后端分离 这个名词，只模糊的知道它最重要的一个作用就是，大大的提升了 前端的地位。 但是平时在开发的时候，我也会想奶奶的，没有接口这前端不就写了一个破页面，后期还的和后端对接口，对接口的时候花费的时间，肯定是不比前端开发的时候短，工期上最起码一半一半吧， 这也就前后端分离 ，我这个小脑袋就不是太明白了。

不过我现在是终于搞明白这个问题了， 对于前端来讲，真正的前后端分离，标志是不依赖后端的前端工作开发完成，项目基本宣告结束。 后端开发完接口，只需要提换一个 URL 就行了，这也意味着前端需要去写一些接口。

除了带来开发任务稍微重点外，我至少看到了两个最大的优点：

我体会最深就是这两点。

插曲 ：对了，今天中午我捡到一个手机，我必须要用一张动图来描述下：

这个经典的 GIF ，来自郑伊健的恐怖电影「第一诫」，清凉一冬，绝对值得一看，虽然剧情有很大的 bug ，但是港片就这点好，它有很抓人的地方，让你觉得特别好看。

正文由此开始：

待续~~~

上面三种方案都可以，但你要知道接口很多，需要支持批量引入，所以 使用 Axios 响应拦截器 就不太可取，只能在这简单的造些假数据。

著名开源项目 vue-element-admin 开发环境下模拟假接口使用的是 在 webpack-dev-server 的 before 处拦截。生产环境下是在项目入口文件（ index,js ）使用 Mock.mock 模拟的。

拦截请求的步骤如下，根据 devserverbefore 配置的栗子🌰：

可知道 before 接收一个函数，函数的第一个参数一般叫 app ，因为它的作用和 express 的 app 是等效的。也就是说这个 app 自带路由， 正好解决接口批量引入的问题。

在项目中，一般都是这么写，把逻辑提出去：

./mock/mock-server.js 文件的内容为：

./mock/index.js 文件的内容为：

mockXHR 不用看，因为这是给线上环境用的，所以可以简单的改写为：

随便找一个，例如 user 看下接口怎么写的：

完美，到此结束。

我想你一定对更改文件的时候，为什么要 清路由和清缓存感兴趣。

如果熟悉 express 框架，看到 app._router.stack 你就知道了。不知道也没关，我演示给你看，新建一个JS 文件，文件内容为：

执行结束，看在 test.js 文件的内容：

发现没，重复被添加的路由，不是覆盖而是扩展。

这个涉及到 CJS 模块的运行机制， 记住 require 的文件会被加到 require.cache 里面，当文件改变读的是缓存，而不是最新更改的文件。

项目结构过大，如果只在 mock 文件夹里面管理有点麻烦，我就想在页面所在目录直接写接口，怎么办？没错使用 require.context 来批量引入。但是 NodeJs 是没有批量引入的 API 的。找遍了 npm 也没发现一个 package 和 require.context 长得像的。

难道没办法了吗？当然不是，自己动手丰衣足食。 依照 vue-cli 插件的命名规范，我给写的 package 取名 node-plugin-require-context ，简单讲下实现原理：

其实还有一个缺点，如果你看过 Antd-Pro 项目，你就会发现它模拟数据，模块化采用的是 ESModule ，而不是 CJS。保持编码模块化风格一致确实也是需要优化的一个地方，不管了，反正我不干。

官网本来就是中文的，我在使用中发现写的贼好，我就不用画蛇添足了。建议每次使用前：

mockjs 使用简介

在前后端分离的开发模式中，数据需要通过 http 请求异步从服务器端获取，也就是前端开发需要依赖后端接口，如果不能时时保证数据获取通畅，就会造成开发阻塞。这时前端需要一种方式可以来模拟数据请求，从而更多的掌握主动权独立开发项目， mockjs 可以以无侵入的方式拦截 ajax 请求，通过模拟服务器端响应来返回数据

JSRUN

Mockjs 语法规范由数据模板定义规范和数据占位符定义规范组成，在官网的 示例文档 中提供了丰富的模板定义方法，可点击查看

Mockjs 实现的原理是对 XHR 对象的拦截，属于 js 拦截，并没有通过浏览器发出请求，所以一般会碰到以下问题。

为了处理以上问题，引入集成了 mockjs 的 mock server工具 easy-mock ，注册并登录 easy-mock 官网后，会有一个演示项目提供参考，参考演示项目可以轻松创建自己的项目，如下图

创建项目后可以基于当前项目创建请求接口，如下图，创建一个 url 为 \user 的 get 请求，会生成接口为 https://www.easy-mock.com/mock/5b97a508b158375129f1b724/hello/user 的完整地址，点击 用户列表 可查看返回数据，由于 easy-mock 内部集成了 mockjs ，所以在生成数据时可以采用mockjs数据模板来生成，把基础用法中的数据生成模板粘贴过来，可以生成相同数据
浏览器限制跨域访问，所以要访问到接口数据，还需要解决跨域问题，通过 Nginx 解决跨域我在另外一片文章有讨论过，点击可以可查，下面主要介绍下通过 webpack-dev-server 设置代理

假设本地请求的根路径为 http://localhost:8080 ，通过 ajax 请求 用户列表 的完整接口为 http://localhost:8080/proxy/user ， webpack-dev-server 通过代理方式将请求转发到我们在 easy-mock 中定义的接口 https://www.easy-mock.com/mock/5b97a508b158375129f1b724/hello/proxy/user ，此时接口地址中多了个代理标志 /proxy , 通过配置参数 pathRewrite: {'^/proxy': ' '} 将 /proxy 去掉即可。

【Mock.js】前端模拟假数据，不用在手拼了

前后端分离开发的时候，前端和后端是并行开发的，前端往往刚开始不能拿到测试的数据，都需要自己写测试数据。 编写测试数据还是比较浪费时间的，虽然简单，但是都是体力活。

那么是否有工具可以帮我们生成数据，生成API接口，让前端能够爽爽的开发。

Mock.js 正是这样一款类库，可以帮我们模拟生成一堆数据。

引入引入mock.js的包，然后生成数据。

生成的数据(数据的个数，1-10个中随机个数)

配置模拟数据

发送Ajax请求：

返回数据：

注意：

属性名 和 生成规则 之间用 | 分隔。生成规则 是可选的。生成规则 有 7 种格式：

生成规则 的 含义 需要依赖 属性值 才能确定。
属性值 中可以含有 @占位符。
属性值 还指定了最终值的初始值和类型。

不懂前后端分离？这篇就够

前后端分离前我们的开发协作模式一般是这样的：

前端写好静态的HTML页面交付给后端开发。静态页面可以本地开发，也无需考虑业务逻辑只需要实现View即可。

后端使用模板引擎去套模板，同时内嵌一些后端提供的模板变量和一些逻辑操作。

然后前后端集成对接，遇到问题，前台返工，后台返工。

然后在集成，直至集成成功。

这种模式的问题

在前端调试的时候要安装完整的一套后端开发工具，要把后端程序完全启动起来。遇到问题需要后端开发来帮忙调试。我们发现前后端严重耦合，还要要求后端人员会一些HTML，JS等前端语言。前端页面里还嵌入了很多后端的代码。一旦后端换了一种语言开发，简直就要重做。

像这种增加了大量的沟通成本，调试成本等，而且前后端的开发进度相互影响，从而大大降低了开发效率。

前后端分离并不只是开发模式，而是web应用的一种架构模式。在开发阶段，前后端工程师约定好数据交互接口，实现并行开发和测试；在运行阶段前后端分离模式需要对web应用进行分离部署，前后端之前使用HTTP或者其他协议进行交互请求。

1. 客户端和服务端采用RESTFul API的交互方式进行交互

2. 前后端代码库分离

在传统架构模式中，前后端代码存放于同一个代码库中，甚至是同一工程目录下。页面中还夹杂着后端代码。前后端工程师进行开发时，都必须把整个项目导入到开发工具中。

前后端代码库分离，前端代码中有可以进行Mock测试(通过构造虚拟测试对 象以简化测试环境的方法)的伪后端，能支持前端的独立开发和测试。而后端代码中除了功能实现外，还有着详细的测试用例，以保证API的可用性，降低集成风险。

3. 并行开发

在开发期间前后端共同商定好数据接口的交互形式和数据格式。然后实现前后端的并行开发，其中前端工程师在开发完成之后可以独自进行mock测试，而后端也可以使用Postman等接口测试软件进行接口自测，然后前后端一起进行功能联调并校验格式，最终进行自动化测试。

分离后，开发模式是这样的

为优质产品打造精益团队

通过将开发团队前后端分离化，让前后端工程师只需要专注于前端或后端的开发工作，是的前后端工程师实现自治，培养其独特的技术特性，然后构建出一个全栈式的精益开发团队。

提升开发效率

前后端分离以后，可以实现前后端代码的解耦，只要前后端沟通约定好应用所需接口以及接口参数，便可以开始并行开发，无需等待对方的开发工作结束。与此同时，即使需求发生变更，只要接口与数据格式不变，后端开发人员就不需要修改代码，只要前端进行变动即可。如此一来整个应用的开发效率必然会有质的提升。

完美应对复杂多变的前端需求

如果开发团队能完成前后端分离的转型，打造优秀的前后端团队，开发独立化，让开发人员做到专注专精，开发能力必然会有所提升，能够完美应对各种复杂多变的前端需求。

增强代码可维护性

前后端分离后，应用的代码不再是前后端混合，只有在运行期才会有调用依赖关系。应用代码将会变得整洁清晰，不论是代码阅读还是代码维护都会比以前轻松。

使用了前后端分离架构后，除了开发模式的变更，我们在开发的过程中还会遇到哪些问题呢？我们接着往下看。

我们先来看看传统开发，我们是如何进行用户认证的

前端登录，后端根据用户信息生成一个jsessionid，并保存这个 jsessionid 和对应的用户id到Session中，接着把 jsessionid 传给用户，存入浏览器 cookie，之后浏览器请求带上这个cookie，后端根据这个cookie值来查询用户，验证是否过期。

HTTP有一个特性：无状态的，就是前后两个HTTP事务它们并不知道对方的信息。而为了维护会话信息或用户信息，一般可用Cookie和Session技术缓存信息。

- Cookie是存储在客户端的

- Session是存储在服务端的

但这样做问题就很多，如果我们的页面出现了 XSS 漏洞，由于 cookie 可以被 JavaScript 读取，XSS 漏洞会导致用户 token 泄露，而作为后端识别用户的标识，cookie 的泄露意味着用户信息不再安全。尽管我们通过转义输出内容，使用 CDN 等可以尽量避免 XSS 注入，但谁也不能保证在大型的项目中不会出现这个问题。

在设置 cookie 的时候，其实你还可以设置 httpOnly 以及 secure 项。设置 httpOnly 后 cookie 将不能被 JS 读取，浏览器会自动的把它加在请求的 header 当中，设置 secure 的话，cookie 就只允许通过 HTTPS 传输。secure 选项可以过滤掉一些使用 HTTP 协议的 XSS 注入，但并不能完全阻止。

httpOnly 选项使得 JS 不能读取到 cookie，那么 XSS 注入的问题也基本不用担心了。但设置 httpOnly 就带来了另一个问题，就是很容易的被 XSRF，即跨站请求伪造。当你浏览器开着这个页面的时候，另一个页面可以很容易的跨站请求这个页面的内容。因为 cookie 默认被发了出去。

解决方案

JWT（Json Web Token）

JWT 是一个开放标准(RFC 7519)，它定义了一种用于简洁，自包含的用于通信双方之间以 JSON 对象的形式安全传递信息的方法。该信息可以被验证和信任，因为它是数字签名的。JWTS可以使用秘密（使用HMAC算法）或公钥/私钥对使用RSA或ECDSA来签名。

- 简洁(Compact)：可以通过URL, POST 参数或者在 HTTP header 发送，因为数据量小，传输速度快。

- 自包含(Self-contained)：负载中包含了所有用户所需要的信息，避免了多次查询数据库。

JWT 组成

JWT由3个子字符串组成，分别为Header，Payload以及Signature，结合JWT的格式即：Header.Payload.Signature。（Claim是描述Json的信息的一个Json，将Claim转码之后生成Payload）。

Header

Header是由下面这个格式的Json通过Base64编码（编码不是加密，是可以通过反编码的方式获取到这个原来的Json，所以JWT中存放的一般是不敏感的信息）生成的字符串，Header中存放的内容是说明编码对象是一个JWT以及使用“SHA-256”的算法进行加密（加密用于生成Signature）

- 头部包含了两部分，token 类型和采用的加密算法

- Base64是一种编码，也就是说，它是可以被翻译回原来的样子来的。它并不是一种加密过程。

Payload

Payload是通过Claim进行Base64转码之后生成的一串字符串，Claim是一个Json，Claim中存放的内容是JWT自身的标准属性，所有的标准属性都是可选的，可以自行添加，比如：JWT的签发者、JWT的接收者、JWT的持续时间等；同时Claim中也可以存放一些自定义的属性，这个自定义的属性就是在用户认证中用于标明用户身份的一个属性，比如用户存放在数据库中的id，为了安全起见，一般不会将用户名及密码这类敏感的信息存放在Claim中。将Claim通过Base64转码之后生成的一串字符串称作 Payload 。

Signature

Signature是由Header和Payload组合而成，将Header和Claim这两个Json分别使用Base64方式进行编码，生成字符串Header和Payload，然后将Header和Payload以Header.Payload的格式组合在一起形成一个字符串，然后使用上面定义好的加密算法和一个密匙（这个密匙存放在服务器上，用于进行验证）对这个字符串进行加密，形成一个新的字符串，这个字符串就是 Signature 。

签名的目的： 最后一步签名的过程，实际上是对头部以及负载内容进行签名，防止内容被窜改。如果有人对头部以及负载的内容解码之后进行修改，再进行编码，最后加上之前的签名组合形成新的JWT的话，那么服务器端会判断出新的头部和负载形成的签名和JWT附带上的签名是不一样的。如果要对新的头部和负载进行签名，在不知道服务器加密时用的密钥的话，得出来的签名也是不一样的。

三个部分通过.连接在一起就是我们的 JWT 了：

JWT认证

服务器在生成一个JWT之后会将这个token发送到客户端机器，在客户端再次访问受到JWT保护的资源URL链接的时候，服务器会获取到这个token信息，首先将Header进行反编码获取到加密的算法，在通过存放在服务器上的密匙对Header.Payload 这个字符串进行加密，比对token中的Signature和实际加密出来的结果是否一致，如果一致那么说明该token是合法有效的，认证成功，否则认证失败。

JWT使用总结

1. 首先，前端通过Web表单将自己的用户名和密码发送到后端的接口。这一过程一般是一个HTTP POST请求。建议的方式是通过SSL加密的传输（https协议），从而避免敏感信息被嗅探。

2. 后端核对用户名和密码成功后，将用户的id等其他信息作为JWT Payload（负载），将其与头部分别进行Base64编码拼接后签名，形成一个JWT。形成的JWT就是一个形同lll.zzz.xxx的字符串。

3. 后端将JWT字符串作为登录成功的返回结果返回给前端。前端可以将返回的结果保存在Cookie或localStorage或sessionStorage上，退出登录时前端删除保存的JWT即可。

4. 前端在每次请求时将JWT放入HTTP Header中的Authorization位。(解决XSS和XSRF问题)

5. 后端检查是否存在，如存在验证JWT的有效性。例如，检查签名是否正确；检查Token是否过期；检查Token的接收方是否是自己（可选）。

6. 验证通过后后端使用JWT中包含的用户信息进行其他逻辑操作，返回相应结果。

JWT和Session方式存储id的差异

Session方式存储用户id的最大弊病在于Session是存储在服务器端的，所以需要占用大量服务器内存，对于较大型应用而言可能还要保存许多的状态。一般而言，大型应用还需要借助一些KV数据库和一系列缓存机制来实现Session的存储。

而JWT方式将用户状态分散到了客户端中，可以明显减轻服务端的内存压力。除了用户id之外，还可以存储其他的和用户相关的信息，例如该用户是否是管理员、用户所在的分组等。虽说JWT方式让服务器有一些计算压力（例如加密、编码和解码），但是这些压力相比磁盘存储而言可能就不算什么了。

单点登录

Session方式来存储用户id，一开始用户的Session只会存储在一台服务器上。对于有多个子域名的站点，每个子域名至少会对应一台不同的服务器，例如：

www.taobao.com，nv.taobao.com，nz.taobao.com，login.taobao.com。所以如果要实现在login.taobao.com登录后，在其他的子域名下依然可以取到Session，这要求我们在多台服务器上同步Session。使用JWT的方式则没有这个问题的存在，因为用户的状态已经被传送到了客户端。

当客户端和服务端分开部署到不同服务器的时候，就会遇到跨域访问的问题，是由浏览器同源策略限制的一类请求场景。

跨域解决方案有很多种，下面使用Nginx反向代理的方案

反向代理

代理访问其实在实际应用中有很多场景，在跨域中应用的原理做法为：通过反向代理服务器监听同端口，同域名的访问，不同路径映射到不同的地址，比如，在nginx服务器中，监听同一个域名和端口，不同路径转发到客户端和服务器，把不同端口和域名的限制通过反向代理，来解决跨域的问题：

前后端分离方案以及技术选型

作者：关开发

一.什么是前后端分离？

理解前后端分离大概可以从3个方面理解：

1. 交互形式

2. 代码组织形式

3. 开发模式与流程

1.1 交互形式

前后端不分离

后端将数据和页面组装、渲染好了之后，向浏览器输出最终的html；浏览器接收到后会解析html，解析引入的css、执行js脚本，完成最终的页面展示。

前后端分离

后端只需要和前端约定好接收以及返回的数据格式（一般用JSON格式），向前端提供API接口。前端就可以通过HTTP请求调用API的方式进行交互。前端获取到数据后，进行页面组装、渲染，最终在浏览器呈现。

1.2 代码组织形式

前后端不分离

在web应用早期的时候，前端页面以及后台业务数据处理的代码都放在一个工程下，甚至放在同一目录下，前端页面夹杂着后端代码。前、后端开发工程师都需要把整套代码导入开发工具才能开发。此阶段下前后端代码以及工作耦合度太高，前端不能独立开发和测试，后端人员也要依赖前端完成页面后才能完成开发。最糟糕的情况是前端工程师需要会后端模板技术（jsp），后端工程师还要会点前端技术，需要口头说明页面数据接口，才能配合完成开发。否则前端只能当一个“切图仔”，只输出HTML、CSS、以及很少量与业务逻辑无关的js；然后由后端转化为后端jsp，并且还要写业务的js代码。

前后端分离

前后端代码放在不同的工程下，前端代码可以独立开发，通过mock/easy-mock技术模拟后端API服务可以独立运行、测试；后端代码也可以独立开发，运行、测试，通过swagger技术能自动生成API文档供前端阅读，还可以进行自动化接口测试，保证API的可用性，降低集成风险。

1.3 开发模式与流程

前后端不分离

在项目开发阶段，前端根据原型和UI设计稿，编写HTML、CSS以及少量与业务无关的js（纯效果那些），完成后交给后台人员，后台人员将HTML转为jsp，并通过JSP的模板语法进行数据绑定以及一些逻辑操作。后台完成后，将全部代码打包，包含前端代码、后端代码打成一个war，然后部署到同一台服务器运行。顶多做一下动静分离，也就是把图片、css、js分开部署到nginx。

具体开发流程如下：图略

前后端分离

实现前后端分离之后，前端根据原型和UI设计稿编写HTML、CSS以及少量与业务无关的js（纯效果那些），后端也同时根据原型进行API设计，并与前端协定API数据规范。等到后台API完成，或仅仅是API数据规范设定完成之后。前端即可通过HTTP调用API，或通过mock数据完成数据组装以及业务逻辑编写。前后端可以并行，或者前端先行于后端开发了。

具体开发流程如下：图略

二、前后端分离的好处与坏处。

从上面3个方面对比了之后，前后端分离架构和传统的web架构相比，有很大的变化，看起来好处多多。到底是分还是不分，我们还是要理性分析是否值得才去做。

从目前应用软件开发的发展趋势来看，主要有两方面需要注意：

· 越来越注重用户体验，随着互联网的发展，开始多终端化。

· 大型应用架构模式正在向云化、微服务化发展。

我们主要通过前后端分离架构，为我们带来以下四个方面的提升：

· 为优质产品打造精益团队

通过将开发团队前后端分离化，让前后端工程师只需要专注于前端或后端的开发工作，是的前后端工程师实现自治，培养其独特的技术特性，然后构建出一个全栈式的精益开发团队。

· 提升开发效率

前后端分离以后，可以实现前后端代码的解耦，只要前后端沟通约定好应用所需接口以及接口参数，便可以开始并行开发，无需等待对方的开发工作结束。与此同时，即使需求发生变更，只要接口与数据格式不变，后端开发人员就不需要修改代码，只要前端进行变动即可。如此一来整个应用的开发效率必然会有质的提升。

· 完美应对复杂多变的前端需求

如果开发团队能完成前后端分离的转型，打造优秀的前后端团队，开发独立化，让开发人员做到专注专精，开发能力必然会有所提升，能够完美应对各种复杂多变的前端需求。

· 增强代码可维护性

前后端分离后，应用的代码不再是前后端混合，只有在运行期才会有调用依赖关系。应用代码将会变得整洁清晰，不论是代码阅读还是代码维护都会比以前轻松。

那么前后端分离有什么不好的地方吗？我目前是没有想到，除非你说会增加前端团队的配备，后端工程师会变的不全能。。。

二、前后端分离架构方案。

实现前后端分离，主要是前端的技术架构变化较大，后端主要变为restfull 风格API，然后加上Swagger技术自动生成在线接口文档就差不多了。

对于目前用于前后端分离方案的前端技术架构主要有两种：

· 传统SPA

· 服务端渲染SSR

2.1 传统SPA

传统SPA指的是单页面应用，也就是整个网站只有一个页面，所有功能都通过这一个页面来呈现。因为一个人的肉眼，某一个时间点看一个页面，既然如此何必要不同功能做多个页面呢？只保留一个页面作为模板，然后通过路由跳转来更新这个模板页面的内容不就可以了吗？确实如此，现在通过reac全家桶、tvue全家桶，模块化、路由、wabpack等技术轻而易举就能实现一个单页面应用。

单页面应用的运行流程

1.用户通过浏览器访问网站url

2.单页面的html文件（index.html）被下载到浏览器，接着下载html里面引用的css，js。

3.css，js下载到浏览器完成之后，浏览器开始解析执行js向后端服务异步请求数据。

4.请求数据完成后，进行数据绑定、渲染，最终在用户浏览器呈现完整的页面。

2.2 服务端渲染

服务端渲染的方案指的是数据绑定，渲染等工作都放在服务端完成，服务端向浏览器输出最终的html。大家看完这个是不是有个疑问，这不是又回到了前后端不分离的时代了吗？答案是否定的，因为这里的服务端是用来执行前端数据绑定、渲染的，也就是把浏览器的一部分工作分担到了服务端。而目前具备这只种能力的服务端是NodeJs服务端。

它的原理其实就是在浏览器与前端代码中间插入了一个NodeJs服务端。浏览器请求前端页面时，会先经过NodeJS服务端，由NodeJs去读取前端页面，并执行异步后端API，获取到数据后进行页面数据绑定，渲染等工作，完成一个最终的html然后返回浏览器，最后浏览器进行展示。

服务端渲染应用的运行流程：

1.用户通过浏览器访问网站url

2.NodeJS服务端接收到请求，读取到对应的前端html，css，js。

3.NodeJS解析执行js向后端API异步请求数据。

4.NodeJs请求数据完成之后，进行数据绑定、渲染，得到一个最终的html。

5.NodeJs向浏览器输出html，浏览器进行展示。

PS：其实本质就是把前端编写成一个nodeJs的服务端web应用。实施服务端渲染后，我们最终运行的是一个Nodejs服务端应用。而单页面应用是把静态页面部署到静态资源服务器进行运行。

看到这里，你是否又有疑问，为什么要这么麻烦搞服务端渲染呢？

2.3 SPA与服务端渲染方案对比

SPA的优点是开发简单，部署简单；缺点是首次加载较慢，需要较好的网络，不友好的SEO。

so，以下就是使用服务端渲染的理由了（摘取vue官方说法）：

与传统 SPA (单页应用程序 (Single-Page Application)) 相比，服务器端渲染 (SSR) 的优势主要在于：

· 更好的 SEO，由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面。

请注意，截至目前，Google 和 Bing 可以很好对同步 JavaScript 应用程序进行索引。在这里，同步是关键。如果你的应用程序初始展示 loading 菊花图，然后通过 Ajax 获取内容，抓取工具并不会等待异步完成后再行抓取页面内容。也就是说，如果 SEO 对你的站点至关重要，而你的页面又是异步获取内容，则你可能需要服务器端渲染(SSR)解决此问题。

· 更快的内容到达时间 (time-to-content)，特别是对于缓慢的网络情况或运行缓慢的设备。

无需等待所有的 JavaScript 都完成下载并执行，才显示服务器渲染的标记，所以你的用户将会更快速地看到完整渲染的页面。通常可以产生更好的用户体验，并且对于那些「内容到达时间(time-to-content) 与转化率直接相关」的应用程序而言，服务器端渲染 (SSR) 至关重要。

使用服务器端渲染 (SSR) 时还需要有一些权衡之处：

· 开发条件所限。浏览器特定的代码，只能在某些生命周期钩子函数 (lifecycle hook) 中使用；一些外部扩展库 (external library) 可能需要特殊处理，才能在服务器渲染应用程序中运行。

· 涉及构建设置和部署的更多要求。与可以部署在任何静态文件服务器上的完全静态单页面应用程序 (SPA) 不同，服务器渲染应用程序，需要处于 Node.js server 运行环境。

· 更多的服务器端负载。在 Node.js 中渲染完整的应用程序，显然会比仅仅提供静态文件的 server 更加大量占用 CPU 资源 (CPU-intensive - CPU 密集)，因此如果你预料在高流量环境 (high traffic) 下使用，请准备相应的服务器负载，并明智地采用缓存策略。

以vue为例，实施服务端渲染可以查看官方指南： https://ssr.vuejs.org ，或选择Nuxt.js

2.4 预渲染技术

如果你调研服务器端渲染 (SSR) 只是用来改善少数营销页面（例如 /, /about, /contact 等）的 SEO，那么你可能需要预渲染。无需使用 web 服务器实时动态编译 HTML，而是使用预渲染方式，在构建时 (build time) 简单地生成针对特定路由的静态 HTML 文件。优点是设置预渲染更简单，并可以将你的前端作为一个完全静态的站点。

如果你使用 webpack，你可以使用 prerender-spa-plugin 轻松地添加预渲染。它已经被 Vue 应用程序广泛测试 - 事实上，作者是 Vue 核心团队的成员。

prerender-spa-plugin: https://github.com/chrisvfritz/prerender-spa-plugin

三、前后端分离技术选型

- artTemplate + bootstrap（不推荐， 不算完全前后端分离）

- vue全家桶（推荐）

- react全家桶 （推荐，生态全）

mock.js的使用方法

在开发过程中，有很多前后端分离mock工具的ajax请求，前后端分离开发你肯定遇到这样的问题，后台给你的接口文档，你需要在本地模拟数据返回，可能你也用到过我之前用的蠢方法，就是新建一个test.json文件，放入接口文档中写的返回示例，这么做有个很大的问题是不够灵活，而且还需要切换url，现在学会使用mock.js拦截ajax请求，更加方便的构造你需要的假数据。

在这里我举的例子是在vue项目中如何使用mock.js。

这里我举例最常用的格式
Mock.mock(url,data);
url用正则写，这样get请求传参时，也能拦截数据前后端分离mock工具了。

不设置延时很有可能遇到坑，这里需要留意，因为真实的请求是需要时间的，mock不设置延时则是马上拿到数据返回，这两个情况不同可能导致在接口联调时出现问题。所以最好要先设置延时请求到数据。

生成规则和示例：

Mock.Random 提供的完整方法（占位符）如下：

关于前后端分离mock工具和前后端分离用什么技术的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 前后端分离mock工具的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于前后端分离用什么技术、前后端分离mock工具的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。