说说前后端分离

最近几年web端的前后端分离开发模式似乎很火。搞得哪个公司如果没有前后分离就会显得很LOW似的，于是纷纷加入到前后端分离大队，风风火火的开始搞分离。可分离后的收益却并没有显著提升，有的反而会把简单的问题复杂化。所以到底要不要分离，如何分离，这其实是个值得想一下的问题。

先来说说实现前后端分离的几种解决方案。

第一种：前端MVC+后台接口。

现在主流的前端MV*三大框架，如angular，react，vue，都是实现前后分离的利器。具体三大框架的使用在这里就不多说了。我们主要通过跨域（这里，跨域的手段也有很多：jsonp、反向代理、server设置header）调接口拿到数据，然后利用框架去渲染出dom，并实现逻辑。

这种实现分离的方案的弊端主要是不利于SEO。原因是dom全部通过JS异步去渲染，爬虫无法爬到数据。目前解决的方案也有，比如SSR(服务端渲染)。现在这几个框架也提供了相对应的SSR解决方案。

第二种：nodejs中间层+后台接口

这是另一种实现前后分离的一个方式。通过nodejs调用后台接口，并渲染页面。目前nodejs有非常多的框架可以使用，比如express,koa等等。这种方式的弊端在于，由于js功力不足所导致的性能问题，因此这种方式很考验前端的js水平。并且需要一个靠谱的前端架构人员。

下面说一说为什么要前后分离以及在什么情况下才有必要分离。

我们为什么要做前后端分离呢？

原因恐怕有几个。1、前后端做自己最擅长的事情，避免沟通上的成本。2、缓解后端服务器压力。3、由于前后端不是一个端口，甚至不是一个服务器，不存在后台爆炸页面就挂的情况，前端体验更加友好。

什么情况下分离？

个人觉得满足以下几点，就可以做分离：

1、人员配置上，前端人数比较多，后端人数少一些，或二者持平。

2、前端水平不错，js写得很6。

3、项目SEO要求不高。