前后端是否应该分离
目前对于web来说，前后端分离越来越流行了，很多网站开始向这个方向靠拢。那么为什么有些人要选择前后端分离，前后端分离有什么好处，不做前后端分离应该如何更新架构来适应前后分离带来的部分好处呢？
为什么选择前后端分离
- 传统网站开发过程中，前端写好静态demo，后端翻译成vm，jsp等模板，这种模式问题相信被很多后台人吐槽了很久。
- 后台人员可能直接兼顾前端的功能，一边实现api接口，一边开发页面，两者相互切换，动态拼接页面等等导致后台开发压力增大，前后端分配不均，开发效率缓慢，代码难以维护。如果前后端分离的话，则很好解决前后分工不均的问题，将跟多的逻辑分配给前端来处理，后端专注其本职工作，比如提供api接口，进行权限控制，进行运算工作等。而前端开发人员则可以利用nodejs来搭建自己的本地服务器，直接在本地开发，然后通过一些插件来将api请求转发到后台，这样就可以完全模拟线上的场景，并且与后台解耦。前端可以独立完成与用户交互的整一个过程，两者都可以同时开工，不互相依赖，开发效率更快，而且分工比较均衡。
如何实现前后端分离
-
一般来说，要实现前后端分离，前端就需要开启一个本地的服务器来运行自己的前端代码，以此来模拟真实的线上环境，并且，也是为了更好的开发。因为你在实际开发中，你不可能要求每一个前端都去搭建一个java环境，并且在java环境下开发，这对于前端来说，学习成本太高了。但如果本地没有开启服务器的话，不仅无法模拟线上的环境，而且还面临到了跨域的问题，因为你如果写静态的html页面，直接在文件目录下打开的话，你是无法发出ajax请求的(浏览器跨域的限制),因此，你需要在本地运行一个服务器，可是又不想搭建陌生而庞大的java环境，怎么办法呢？nodejs正好解决了这个问题。在我们项目中，我们利用nodejs的express框架来开启一个本地的服务器，然后利用nodejs的一个http-proxy-middleware插件将客户端发往nodejs的请求转发给真正的服务器，让nodejs作为一个中间层。这样，前端就可以无忧无虑的开发了。
为什么要引入nodejs作为中间层
- 我觉得引入nodejs主要是为了分层开发，职责划分，nodejs作为前端服务器，由前端开发人员负责，前端开发人员不需要知道java后台是如何实现的，也不需要知道API接口是如何实现的，我们只需要关心我们前端的开发工作，并且管理好nodejs前端服务器，而后台开发人员也不需要考虑如何前端是如何部署的，他只需要做好自己擅长的部分，提供好API接口就可以；
- nodejs本身有着独特的异步、非阻塞I/O的特点，这也就意味着他特别适合I/O密集型操作，在处理并发量比较大的请求上能力比较强，因此，利用它来充当前端服务器，向客户端提供静态文件以及响应客户端的请求，我觉得这是一个很不错的选择
前后端分离问题
- 跨域问题
- 安全问题
- 权限问题
非前后端分离更好的解决方案
spring mvc + mybatis-plus + mysql + shiro + httl + jquery + sea.js
spring mvc:这个就不用说了
mybatis-plus: 这个谁用谁知道
shiro：授权认证
sea.js:模块化
httl:高性能的开源java模板引擎， 适用于动态html页面输出， 可替代jsp页面， 指令和veicity相似。
<!--#set(List<Book> books)-->
<html>
<body>
<!--#if(books)-->
<table>
<!--#for(Book book : books)-->
<tr>
<td>${book.title}</td>
</tr>
<!--#end-->
</table>
<!--#end-->
</body>
</html>
HTTL将模板编译成JAVA字节码运行，并使用强类型推导，减少运行期反射和转型， 渲染速度接近Java硬编码输出，比Velocity等其它模板引擎快一个数量级。 比JSP也快，因为JSP只有Scriptlet是编译的，Tag和EL是解释执行的，而HTTL是全编译的.
同时不影响前端开发，注释型语法避免两端冲突，同时部分前端难以实现的逻辑处理可以交给后台，前端直接调用后台方法，这样可以避免前端注入，提高安全性，操作性。
