开发过程中前端和后端的分离已经成为一种共识，显然，前端和后端的分离并不是指开发工作完全分离开来。因为前端开发和失调是需要后台Web容器支持的，很难做到真正的分离，而且设计中动态和静态内容容易混在一起，分流处理的时候非常麻烦。然而有些通过API解耦前端和后端开发过程，前端和后端可以解决一些问题问题并且进行分别开发和部署，但是在集成的过程依然是避免不了产生前端和后端应用的问题。力洋网络认为，前端和后端都会有自己的开发过程、构建工具以及测试集合，而比较理想的工作场景是后台只负责数据提供以及计算，前端负责提取数据，组织数据，展现数据，如此的结构清晰，而且前后端也会相对独立和松耦合。

    上面提到的是理想的工作环境，但是实际的情况显然更为复杂，例如异构网络或者是异构操作系统，后端显得更为负责。一个例子说明：用C做的数据收集，通过Java整合到数据仓库，再通过一层Web service，并且通过聚合service整合返回至前端。这么复杂的一个系统当中，后台的工作如果失败了都会影响到前端开发流程。有些有经验的处理方法则是使用静态服务器，提供mock数据，但这是远不够的，mock应该做到的不止这些，例如让前端进行UI开发，或者是前端的开发和册数，对于后端来说需要测试确保生产的mock数据是前端需要的。也就是说，要保证这些需要一些约定，或者说是中间格式，降低集成时的一些不必要浪费。这里所说的约定，可是是一个JSON文件，或者是XML的payload，保证前后端共享同一个约定集合来测试。小编认为可以提供一些静态的mock文件，同时前端所有发往后台的请求都被某种机制拦截，并转换成对该静态资源的请求。

    在前端和后端实现分离时候，更多的是可以保证到代码的质量同时降低集成的成本，设置好了之后，再实际服务进行的过程中可以简化到链接一个服务器就可以实现。当然，前后端分离也是比较容易实现的，团队中很容易在短时间里面发现其中的好处，但是，需要认真处理集成的问题。分离会导致更长时间的集成，通过约定的方式组织各自的测试，减少资源浪费，更快速、平滑的集成以及分离开发。