⑴ 谈谈前后端分离、模板引擎
答：有两种方式。
前后端分离：也就是后端服务化，客户端先拿到的是静态的html，然后再通过Ajax请求向spring boot后端接口获取JSON数据，然后再在前端渲染html。
服务器端渲染:客户端发起请求，后端servlet接收请求，交给对应请求路径的controller执行对应方法，方法返回ModelAndView给模板引擎，引擎再根据View找到模板（静态html）并将Model（一般是map集合）渲染到模板中，再把渲染好的模板写入响应，这是一个完整的MVC流程。此时客户端拿到的是已经渲染好的视图（也就是注入了模板数据的html）。
⑵ Web 前后端为什么需要分离
我理解的前端就是负责所有和用户交互有关的模块都可以视为前端，他就像餐馆里面的前台服务生直接和客户打交道的人。
后端就是负责处理用户的请求，进行数据的处理，用户几乎所有操作都可以抽象为对数据的增删改查，就像餐馆里面的厨师接收服务生告诉他要炒哪些菜，厨师把菜处理好再给服务生（后端处理数据返回给前端表现层）服务生最后输出给客户。
但是目前由于很多情况下业务比较简单，比如说一个内容发布系统 CMS ，用户交互，请求查看文章和管理员新增文章都是很简单的业务逻辑，所以前后端都用 php 这门主要用于表现层的语言来实现，而本身在用 MVC 模式把用户交互部分（ V 和 C ）以及数据处理（主要是 M ），否则的话就得用 java 等非脚本语言来实现保证效率，甚至高并发环境下还要用到消息队列，缓存等等。
⑶ 前后端分离，用伪静态还有意义吗
比如点击获取更多这种ajax 前后端分离完善的话 伪静态就没意义，但是有些框架前后端分离不完善的比如yii 这些的话还是使用伪静态的好，既然都考虑伪静态了，为什么不让后端做缓存呢？
⑷ 如何使用webpack，proxy实现前后端分离，并且方便后期前后端联调
分离的痛点是分离后，接口提供不及时，文档不完善，模拟数据不方便等。说一下我们的解决办法：
1）webpack设置proxy，这个通过webpack文档或GOOGLE一下可以解决。
2）第二步就是需要在后端提供接口及数据和接口文档，而因为前后端很可能是并行开发的，所以在真实接口出来之前需要前端模拟接口及数据，及数据文档然后在真实接口出来后，切换到真实接口调试，我们之前也遇到过此问题，所以抽时间自己做了个mocksever 系统，功能包括:
支持可视化编辑JSON接口数据及接口文档
支持GET、POST、PUT、DELETE请求类型
支持指定返回状态码，默认200
支持延时返回数据
支持mockjs
支持单个接口代理到真实服务器(开发过程中某个接口使用模拟数据,当此接口已开发完成后,可将指定接口,通过此服务指向到真实接口上)
⑸ 基于Docker-Compose 部署前后端分离单体项目(一)
1.单体项目是否需要采用docker进行部署?
2.如果采用docker部署是否有必要采用docker-compose进行服务编排？
答案是也许有必要，也许没必要，docker的优势很多，但是对于垂直架构的项目优势未必那么明显，总之一句你需要根据自己的项目情况去考虑。笔者之所以会写这篇文章，大概率是基于省事的目的去部署一些小的项目。同时也是提供一种前后端分离的项目的部署方案(但绝对不是最有方案),以及在这种模式下的docker如何去工作才能达到我们的目的。
然而最终的目的是为了偷懒，省事。让前后端分离项目的部署方式变的简单。就也许在这种模式下，你只需要5分钟就可以实现部署，或许吧，不妨把这个当作一个目标。
本文目标:
上图将部署流程分为三部分，本地开发环境，阿里云容器镜像服务，以及linux服务器。下面分成三个部分对上图进行说明，工欲善其事，必先利其器。先进行说明，后面才能对每部分做的工作比较清晰。
本地开发环境分成三个项目
先解释一下图中的相关名词
容器镜像服务，分门别类的存储我们的镜像 。这个是镜像服务的唯一用途，就相当于maven的仓库是一样的。
我们也可以搭建自己的私服仓库，例如开源的harbor等，都非常好用，在企业中用私服会比较多。
首先我们需要在linux服务器上搭建Docker环境，也就是我们在linux上有一个docker。再将我们的镜像运行在docker上。
从上图我们发现在docker上运行这很多容器，mysql，redis，nginx，pitaya-java,pitaya-admin,pitaya-h5.
然而我们的容器是需要通信的，例如:大家都知道pitaya-java是一个springboot的项目，他需要访问mysql进行数据存储服务，需要访问redis缓存我们的令牌信息等。
也就是说，我们运行的这些容器之间是要相互能通信的。所以我们在docker上创建了一个内部网络叫做pitaya-network，他在172.2.0.0这个网段，我们需要我们的容器都加入pitaya-network这个网络，并且分配固定的IP地址,指定固定端口。
为什么需要分配固定IP地址，指定固定端口? 因为我们的容器也可能会和服务器一样，会挂掉，如果随机分配的话，创建新的容器，IP地址可能会变，我们容器间不能通信，例如java服务访问不了mysql，这样我们的线上就无法提供客户正常服务了。
本文我们做一个大概的概述，针对上面的结构以下问题是我们急需解决的？
其实针对java项目和vue项目制作镜像方式不同，但是原理一样，原理无非就是基于docker build这个命令制作镜像，但是java的镜像制作和推送可能更加简单，只需要一条命令即可，因为maven提供了制作镜像的插件。这些内容在下一篇文章都会涉及到！
想要表达清楚一键事情是非常不容易的事情，特别是通过文字，既不想废话连篇，又想表达清楚真的很难，因为细节比较多！然而我觉得弄清楚大方向是非常必要的，然后再进行分解，希望能说的明白，我会加油的，如果写的不好也希望大家原谅！
⑹ 如何进行前后端分离
在不使用vue ,react ,anglar这类的框架的情况下，前后端分离应该如何做？
需求是这样：
前端写html页面（非单页面应用），
index.html 首页
about.html 关于我们
newslist.html 新闻列表
newsdetail.html 新闻详情
proctlist.html 产品列表
proctdetail.html 产品详情
后台只提供json数据
那么
1、前端数据如何渲染？
2、页面跳转是否必须使用路由？（不想使用路由）
3、页面间的数据传递如何做，比如：列表页到详情页的参数传递如何做？
⑺ 使用 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 项目，你就会发现它模拟数据，模块化采用的是 ESMole ，而不是 CJS。保持编码模块化风格一致确实也是需要优化的一个地方，不管了，反正我不干。
官网本来就是中文的，我在使用中发现写的贼好，我就不用画蛇添足了。建议每次使用前：
⑻ 前后端分离方案以及技术选型
作者：关开发
一.什么是前后端分离？
理解前后端分离大概可以从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全家桶 （推荐，生态全）
⑼ 前后端分离微服务架构如何设计
前端
前端开发人员专注业务的页面呈现，非常注重用户体验度，也是与各种角色打交道最多的。
比如：
一般前端工作包括六个部分：
后端
如果前后端职责划分很清楚的话，后端更多开发工作在于业务接口设计、业务逻辑处理以及数据的持久化存储，并提供详细的接口设计文档给前端开发人员使用。
一般后端工作包括五个部分：
1、与产品经理对接需求
2、业务 API 接口开发：根据根据需求文档进行业务接口开发
4、接口对接：与前端开发人员接口对接
5、前后端联调测试：包括页面展示以及接口数据
6、bug修复
前端开发技术栈
h5 、 css 、 nodejs / vue / angular / react 、 webpack 、 hbuilder / vscode 等
后端开发技术栈
SpringCloud / Springboot 、 SpringMVC 、 ORM 框架、数据库、缓存框架（ Redis ， Codis , Memcached 等），大数据框架（ Hadoop / Spark / hive / Hbase / Storm / ES / Kafka ）等等
技术选型
最好选择成熟稳定，易上手、开发效率高的技术，因为实际项目开发时间是有限的，开发人员没有多少精力放在学习和深度研究技术上。
数据格式
后端开发提供接口设计文档，详细写明每个接口的请求地址、请求参数、响应参数等等；一般采用 REST 风格以 JSON 格式提供数据。
接口设计
一个接口设计的好坏，直接影响到前后端的一些沟通协调问题。
依笔者的经验来看，如果后端接口不稳定，会导致前端开发人员反复修改页面数据呈现。常常出现后端开发说这是前端问题，前端开发说是后端问题，来回扯皮，沟通效率低下。
接口容量问题
一个接口的业务容量大小，往往代表前后端工作量的大小。
如果一个接口的业务容量太小，前端需要分阶段处理的事情就多，尤其是对多个接口 Ajax 异步处理；
如果一个接口的业务容量太大，那么业务耦合性高，万一需求变更，后端程序改动大，不利于程序的扩展。
一、前后端分离的思想要转变
不能老是按照传统WEB（ js/h5/css/ 后端代码放在一个工程）开发思维去看待前后端分离
二、沟通成本问题
以前传统 WEB 开发，开发人员从需求到设计到开发基本上是一个人。
而前后端分离后，前端只负责页面呈现，后端更注重业务逻辑处理以及数据的持久化，双发都有自己的侧重点，工作量上有私心。
三、组织结构问题
康威定律
第一定律： Communication dictates design （组织沟通方式会通过系统设计表达出来）
第二定律： There is never enough time to do something right, but there is always enough time to do it over （时间再多一件事情也不可能做得美，但总有时间做完一件事情）
第三定律 ： There is a homomorphism from the linear graph of a system to the linear graph of its design organization （线型系统和线型组织架构间有潜在的异质同态特性）
第四定律： The structures of large systems tend to disintegrate ring development, qualitatively more so than with small systems （大的系统组织总是比小系统更倾向于分解）
康威定律说明以下几点
四、部署及监控运维
前后端分离后，拆分的服务会带来线上部署以及如何监控运维的复杂性。
总体来说，前后分离所带来的好处还是更明显的。一个成熟的前后端分离的团队，文档化约定，前后端职责分离、接口约定都是做得比较好的
⑽ Web项目开发为何要走前后端分离模式
把前端与后端独立起来去开发，放在两个不同的服务器，需要独立部署，两个不同的工程，两个不同的代码库，不同的开发人员，前后端工程师需要约定交互接口，实现同步开发，开发结束后需要进行独立部署，前端通过接口来调用调用后端的API，前端只需要关注页面的样式与动态数据的解析和渲染，而后端专注于具体业务逻辑。具体好处有以下几点：
1.彻底解放前端
前端不再需要向后台提供模板或是后台在前端html中嵌入后台代
2.提高工作效率，分工更加明确
前后端分离的工作流程可以使前端只关注前端的事，后台只关心后台的活，两者开发可以同时进行，在后台还没有时间提供接口的时候，前端可以先将数据写死或者调用本地的json文件即可，页面的增加和路由的修改也不必再去麻烦后台，开发更加灵活。
3.局部性能提升
通过前端路由的配置，我们可以实现页面的按需加载，无需一开始加载首页便加载网站的所有的资源，服务器也不再需要解析前端页面，在页面交互及用户体验上有所提升。
4.降低维护成本
通过目前主流的前端MVC框架，我们可以非常快速的定位及发现问题的所在，客户端的问题不再需要后台人员参与及调试，代码重构及可维护性增强。
5.实现高内聚低耦合，减少后端（应用）服务器的并发/负载压力。
6.即使后端服务暂时超时或者宕机了，前端页面也会正常访问，但无法提供数据。
7.可以使后台能更好的追求高并发，高可用，高性能；使前端能更好的追求页面表现、速度流畅、兼容性、用户体验等。
我理解的前后端分离，前端是需要起服务器的，减少学习成本，可以用node，前端也要有域名的
如果是半分离， 那么前端提供js文件（css等）这个我也做过，前后端都用node就不说了，如果是两种语言，
如果一个工程文件下开发，webpack下直接打包进后台语言的静态目录下。
如果是两个工程，那么前端只提供生成的js（css）文件，git pull后台项目，扔进静态目录，这样又涉及到版本控制的问题，一般我会生成一个配置文件，直接读取的，内容是xxx.hash.js这种文件名，然后document.wirte动态写入js/css
前端起服务器就不需要动态引入了，直接html插件生成文件，更好的控制版本
半分离 还有一个问题，例如首页同构，如果更改xxx.blade.php文件，这就又动了php文件，甚至包括nginx反向代理啊，ssl这种缓存啊，都比较麻烦，你要是改了点啥，自己的ok了，后台的崩了，那就挺操蛋了，大公司有专门的运维还好，小公司真的是一团糟
后台我们采取全分离，nginx前端管理，至于升级nginx版本，http2，反向代理，https证书，都是前端自己弄，毕竟小公司，每个人水平都不一致，自己负责自己的比较好
但是这个跨域又要稍微处理一下，至今我这边后台还是*，我也没法说什么
阿里云这么便宜，如果把成本浪费在人力上，会变得很贵
一个人的精力有限，前后端分离有助于我们更专注我们所要注重的技术点，俗话说：“术业有专攻”。
比如我们后端，前后端分离有助于我们把注意力放在java基础，设计模式，jvm原理，spring+springmvc原理及源码，linux，mysql事务隔离与锁机制，mongodb，http/tcp，多线程，分布式架构（bbo，bbox，spring cloud），弹性计算架构，微服务架构（springboot+zookeeper+docker+jenkins），java性能优化，以及相关的项目管理等等。
而前端也可以集中精力在前端的展示上。
总的来说，前后端分离利大于弊。这也是越来越少用jsp的原因。
补充两点
1.每次请求的数据量变小，也意味着更少的响应时间。
2.也不是每个应用用前后端分离都是最合适的，要根据应用规模，工期综合判断。