关于先后端分离与不分离

前端开发者(Frontend Developer)所作的就是开发产品的前端，所谓的 应用产品的前端就是用户看到，接触到和体验到的，他们主要作静态用户界面加上一些动态效果，不涉及数据逻辑，前端考虑到的是用户体验，然后端开发者（Backend Developer）就不同了，他们是在后台工做的，控制着前端的内容，主要负责程序设计架构思想，管理数据库等。

      先后端分离和微服务同样，渐渐地影响了新的大型系统的架构。微服务和先后端分离要解决是相似的问题，解耦——能够解耦复杂的业务逻辑，解耦架构。可要是说相像吧，消息队伍和先后端便类似一些，经过传递数据的形式来解耦组件。

    先后端分离意味着，先后端之间使用 JSON 来交流，两个开发团队之间使用 API 做为契约进行交互。今后，后台选用的技术栈不影响前台。当后台开发人员选择 Java 的时候，我能够不用 JSP 来编写前端页面，继续使用个人 React 又或者 Angular。而我使用 React 时，也不影响后台使用某一个框架。

    过去，据说 TDD (Test-driven development，测试驱动开发) 能够改善代码的质量，咱们便实施了 TDD；接着，据说 BDD (Behavior-driven development，行为驱动开发) 能够交付符合业务需求的软件，咱们便实施了 BDD；后来，据说 DDD (Domain-driven design，领域驱动设计) 能够分离业务代码与基础代码，咱们便实施了 DDD。今天，据说了先后端分离很流行，因而咱们就实施了先后端分离——这就是传说中的 HDD（Hype-driven Development，热闹驱动开发）。

      页面交互是否复杂 ？是简单的提供页面给用户浏览？或者想要支持复杂的用户操做？是否须要搜索引擎优化？若是须要的话，那么从一开始咱们就须要考虑后端渲染。能提高开发效率吗？若是不能有效的提高开发效率，为何要做死呢？是否会提供 API 给 APP？若是咱们已经有一个 API 提供给 APP，那么要作这件事就很容易了。若是将来会有的话，那么咱们更应该尝试去分离。前端的修改是否是很是频繁？若是不须要常常修改的话，那么这种优化便没有优点。

固然了，若是老板说，咱们须要先后端分离，那就作呗！不少时候，一些技术决策都会因为战略缘由，而发生一些有意思的变化。

先后端分离将遇到的那些挑战

当咱们决定须要先后端分离时，咱们仍然还须要面对一系列的问题：

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

当咱们在不一样的项目组上尝试时，就会发现主要的挑战是沟通上的挑战，而非技术上的局限。

先后端分离的核心：后台提供数据，前端负责显示

我曾经有过使用 PHP 和 Java 开发后台代码的经历，仍然也主要是集中在前端领域。在这样的传统架构里，编写前端页面可不是一件容易的事。后台只会传给前端一个 ModelAndView，而后前端就要扑哧扑哧地去丰富业务逻辑。

传统的 MVC 架构里，由于某些缘由有至关多的业务逻辑，会被放置到 View 层，也就是模板层里。换句话来讲，就是这些逻辑都会被放到前端。咱们看到的可能就不是各类if、else还有简单的equal判断，还会包含一些复杂的业务逻辑，好比说对某些产品进行特殊的处理。

若是这个时候，咱们还须要作各类页面交互，如填写表单、Popup、动态数据等等，就再也不是简单的和模板引擎打交道了。咱们须要编写大量的 JavaScript 代码，由于业务的不断增长，仅使用 jQuery 没法管理如此复杂的代码。

     

输出逻辑：数据显示

而仅仅只是由于逻辑复杂的前端代码，没法影响大部分团队进行先后端分离——由于它没有业务价值。其实是先有了单页面应用，才会出现先后端分离。单页面应用可让用户不须要下载 APP，就能够拥有类似的体现。而且与早期的移动网页相比，拥有更好的体验。

为了达到这样的目的，后台彷佛返回对应的 Model 便可，稍微修改一下 Controller 的逻辑，而后返回这些数据。

与此同时，后台应该按时间来对博客进行排序。前端只须要遍历这个数组，随后取出相应的值显示便可，不须要作任何的逻辑处理。

遗憾的是，在真正的项目中开发的时候，并不能达到这么完美的状态。特别是，为了提升用户体验时，咱们可能就会将数据存储在本地，随后直接操做这些数据，对其进行排序，筛选等等的操做。除此，还有诸如表格、图表等等的高级样式，也须要处理这些数据。

而当用户须要提交数据的时候，这些逻辑就会落到前端上。

不可避免的前端逻辑：表单

若是一个前端应用只显示数据的话，那么这个应用就没有充足的理由，作成一个单页面应用——单页面应用是为了更好的交互而存在的。当咱们注册、登陆、购买东西时，就须要开始与表单进行处理。

合理的表单验证模式应该是：双向验证。

前端在用户输入的过程当中就须要实时地检查，是否带有特殊符号、值是不是在容许的范围内、是否是符合相应的规范等等。而不是等用户填写完内容并提交后，再由服务端来告诉用户说，“你的用户名不符合规范”。

服务在收到前端收到的数据后，无论前端有没有进行验证，都应该按后台的逻辑进行验证。

因而乎在这个时候，这些逻辑就被无可避免地放到前台里了。