关于前后端分离的一些思考

最近一直在思考前后端分离的这个问题，对这种技术选型的优点和缺点思考了很长时间，目前我能想到的的2种方式，不知道哪种好，索性写了下来，大家看看

第一种：前后端代码分别放在不同的服务器上(暂且叫物理上分离)；

第二种：前后端代码部署在同一个服务器上，前端全部用.html,部分抛弃.jsp（暂且叫前后端开发职责分离）

下面谈谈2者我能想到的优缺点

第一种：

        优点：

            A:前后端彻底解耦，完全没有关系，便于以后的扩展。吧，后端只提供API
            B：前端开发人员不用去管java项目是否启动，打包报错，只用关心实现数据的渲染
            C：长远发展的话，按照我们以后的采用react，redux前端框架，终将会才用node.js来代替java中的controller层（不是必须的），java只提供API（这是一个长远目标，目前node调用java接口还没有稳定的框架得扩展，目前node配合zookeeper使用是有一个框架，底层是C语言实现的，市场上没有大型，稳定的案例，同时团队在node上技术积累也是不够），
        缺点：
            A：存在跨域问题，目前常见解决跨域有JSONP和反向代理，JSONP的本质是将调用后端API伪装成
            调用xxxx.js,将返回的数据绑定到某个DOM树上缓存起来，然后将这个数据回传到ajax的success方法；
           （因为浏览器是准许调用不同服务器的js，这也是Xss攻击能够实现的原理）,这种方式后端数据必须返回{data:[],success:true,message:"xxx提示信息"}，后端返回的数据都必须用callback包裹起来

                a.json = {data:[],success:true,message:"xxx提示信息"}; //假设a.json这个是后端返回的JSON
                $.ajax(
                ｛
                    dataType：jsonp,
                    data:{},
                    url : a.json,
                    success:function(data){}
                ｝);
                用jsonp的化服务端返回的数据必须得是这样的，callback({data:[],success:true,message:"xxx提示信息"})

，这样显然不利于后端接口，比方其他的服务在同一个域下调用接口是不存在跨域的，就又得把这个callback干掉，很烦碎

或者用基于nginx的反向代理技术的，将前段项目用nginx部署，前端发起的请求，都只发到ngnix，ngnix拦截后，截取参数，然后请求后端提供的API上，拿到数据返回给前端的这个请求，举个例子
后端项目某个API的URL是在www.tianan.com/test/，前端发起的一个请求www.tianan.com/test/ngnix/proxy/?useName='王一'&&id=33&&phone=13613456789，这个请求是发给ngnix服务器，ngnix做个拦截，转换成
www.tianan.com/test/?useName='王一'&&id=33&&phone=13613456789;拿到数据后返回给前端，这样就很好的解决了跨域问题；跨域问题解决了，
B.接下来是session的问题，由于不在同一个服务器，session是没有的，解决办法是每次请求都路径都带上前后端确认唯一的一个密匙token或者每次都带上cookie

第二种：

        优点：

        A：上手快，没有了跨域，session，这些问题
        B:都是html静态页面，也页面加载，调转也是可以不经过Controller的，前端人员不用去熟悉java代码，前后端交互还是通过前后端定义的API
        C:某些js不好实现的东西，还是可以用jsp实现，这个对以后使用shiro等框架自定义的一些标签也有很好的支持，

        缺点：
        A:相对的耦合，html和java代码在一起；
        B：前端人员可能面临打包java项目的问题（解决办法是：调用服务器的API，在开发过程中，对浏览器开启可跨域模式（生产环境就不存在跨域了））

以上是我想到一些；大家看看，头脑风暴一把,，错误的地方还望指正;