小弟我们为什么要尝试前后端分离

我们为什么要尝试前后端分离

这不是一篇纯技术文章，而是一篇分享我个人在前后端分离路上收获的点点滴滴的文章，以此来为准备尝试前后端分离或者想了解前后端分离的童鞋做一个大体的讲解。

尝试与改变

如果你没有尝试过前后端分离的工作流程，那么可以先试想一下这样的流程改变：

把流程从
PM：“我要这个功能”
后端：“这个先找前端做个模板”
前端：“模板做完了”
后端：“我来对接一下，这里样式不对”
前端：“我改完了”
后端：“功能交付”
PM：“春节要加这个活动”
后端：“这个先找前端改个模板”
前端：“模板做完了”
后端：“我来对接一下，这里样式不对”
前端：“我改完了”
后端：“功能交付”

变成
PM：“我要这个功能”
前端：“我要接口”
后端：“接口完成了”
前端：“我来对接一下，功能交付”
PM：“春节要加这个活动”
前端：“需要增加接口”
后端：“接口完成了”
前端：“我来对接一下，功能交付”

由此可见，前后端分离的主要概念就是：后台只需提供API接口，前端调用AJAX实现数据呈现。

现状与分歧

作为一名前端开发人员，我们应该尝试一些新颖的技术，完善每一个细节性的问题，不断突破自我。虽然前后端分离已经算不上什么新颖的技术或思路，但是目前很多后台开发人员甚至前端开发人员都没有接触过。

据我个人的了解，如果在一个部门里，部门人员全是后台开发人员，前端的一些页面也是由后台人员完成的，那么前后端分离对于他们而言可能是一片未知的领域，项目大多是前后端强耦合的，甚至不存在前端的概念。

在不重视前端的公司或部门，不了解前后端分离这也无可厚非。在我刚进入一个全是后台开发人员的部门的时候，整个部门就我一个前端，我刚开始的主要职责就是负责项目前端页面的制作和JS功能的实现，虽然部门有前后端分离的意识，但都不知该如何去实践。在那时，部门的后台人员认为前后端分离就是后台不再需要写HTML和JS了，可以交给前端来做了，然而这只能叫做前后端分工。

以上讲述的是一种情况: 不了解前后端分离，也不知如何去实践的。下面还有一种情况：了解前后端分离，但不想去尝试的。

针对第二种情况，很多人也做过相应的解释，其实这就涉及到“前后端分离的利弊”问题。很多后台人员会认为自己所做的那一套没有问题，即便后台套用前端html也是司空见惯，一直是大势所趋，后台MVC框架也是这么推荐使用的，很合理。这时候前端开发人员在部门中的话语权往往是不够的，或者认为后台开发人员的意见永远是对的，没有主观性。

相反，也有可能是后台开发人员非常推荐前后端分离，而前端开发人员不想去实践的。这时候前端会认为后台开发人员在瞎折腾，之前前后端不分离项目做起来都很顺利，分离了反而会给自己带来额外的工作量和学习成本，而这就取决于前端的技术能力和见识了。

当然，这也是我个人认为的前后端分离所存在的一些现状和分歧所在。

场景与要求

对于前后端分离的应用场景，不是所有的场景都适合，但是大多数项目都能够通过前后端分离来实现。

由于我主要从事企业级后台应用的前端开发工作，个人认为对于后台应用的开发来说，前后端分离带来的利是远大于弊的。

大多数后台应用我们都可以做成SPA应用（单页应用），而单页应用最主要的特点就是局部刷新，这通过前端控制路由调用AJAX，后台提供接口便可以实现，而且这样的方式用户体验更加友好，网页加载更加快速，开发和维护成本也降低了不少，效率明显提升。

同样的，在展示类网站和移动APP页面中前后端分离也同样试用。前后端不分离的情况下，服务端要单独针对Web端做处理，返回完整HTML，这样势必增加服务端的复杂度，可维护性差，而web端需要加载完整的HTML，一定程度上影响网页性能，这对于移动端性能为王的地方非常的不友好。

随着前端技术的发展和迭代，前端MVC框架应运而生，利用目前主流的前端框架，如React、Vue、Angular等我们可以轻松的构建起一个无需服务器端渲染就可以展示的网站，同时这类框架都提供了前端路由功能，后台可以不再控制路由的跳转，将原本属于前端的业务逻辑全部丢给前端，这样前后端分离可以说是最为彻底。下面是一段前端控制路由的代码：

'use strict'

export default function (router) {
    router.map({
        '/': {
            component: function (resolve) {
                require(['./PC.vue'], resolve)
            }
        },
        '/m/:params': {
            component: function (resolve) {
                require(['./Mobile.vue'], resolve)
            }
        },
        '/p': {
            component: function (resolve) {
                require(['./PC.vue'], resolve)
            },
            subRoutes: {
                '/process/:username': {
                    component: function (resolve) {
                        require(['./components/Process.vue'], resolve)
                    }
                }
            }
        }
    })
}

前后端分离的实现对技术人员尤其是前端人员的要求会上升一个层次，前端的工作不只是切页面写模板或是处理一些简单的js逻辑，前端需要处理服务器返回的各种数据格式，还需要掌握一系列的数据处理逻辑、MVC思想和各种主流框架。

优势与意义

对于前后端分离的意义我们也可以看做是前端渲染的意义，我主要总结了下面四点：

1.彻底解放前端

前端不再需要向后台提供模板或是后台在前端html中嵌入后台代码，如：

<!--服务器端渲染 -->
<select>
    <option value=''>--请选择所属业务--</option>
    {% for p in p_list %}
    <option value="{{ p }}">{{ p }}</option>
    {% endfor %}
</select>

这是前后端耦合的，可读性差。

<!--前端渲染 -->
<template>
    <select id="rander">
        <option value=''>--请选择所属业务--</option>
        <option v-for="list in lists" :value="list" v-text="list"></option>
    </select>
</template>

<script>
export default {
    data: {
        return {
            lists: ['选项一', '选项二', '选项三', '选项四']
        }
    }，
    ready: function () {
        this.$http({
            url: '/demo/',
            method: 'POST',
        })
        .then(function (response) {
            this.lists = response.data.lists // 获取服务器端数据并渲染
        })
    }
}
</script>

上面是前端渲染的一段代码，前端通过AJAX调用后台接口，数据逻辑放在前端，由前端维护。

2.提高工作效率，分工更加明确

前后端分离的工作流程可以使前端只关注前端的事，后台只关心后台的活，两者开发可以同时进行，在后台还没有时间提供接口的时候，前端可以先将数据写死或者调用本地的json文件即可，页面的增加和路由的修改也不必再去麻烦后台，开发更加灵活。

3.局部性能提升

通过前端路由的配置，我们可以实现页面的按需加载，无需一开始加载首页便加载网站的所有的资源，服务器也不再需要解析前端页面，在页面交互及用户体验上有所提升。

4.降低维护成本

通过目前主流的前端MVC框架，我们可以非常快速的定位及发现问题的所在，客户端的问题不再需要后台人员参与及调试，代码重构及可维护性增强。

心得与体会

一路走来，项目一个接着一个，从一开始的后台控制路由、后台渲染页面到现在的前端控制路由、前端渲染数据，工作流程和方式都发生了很大的变化。每当遇到下面情形的时候，我都会为前后端分离带来的优势而感慨一番：

项目一开始制作前端页面的时候，我不再需要后台给我配置服务器环境了
项目的前端文件可以在需要调用后台接口的时候丢进服务器就好了，完全不需要事先放进去
增加一个项目页面需要配置路由的时候不再需要让后台同事给我加了，自己前端搞定
前端文件里不再掺杂后台的代码逻辑了，看起来舒服多了
页面跳转比之前更加流畅了，局部渲染局部加载非常快速
页面模板可以重复使用了，前端组件化开发提高了开发效率

等等。面对快速发展的前端，我们应该去适应其带来的工作方式和流程的改变，目前的前后端分离的工作方式必然是今后的趋势所在，作为一个前端开发人员，我们应当承担这个普及前端新知识和改变现状的职责。

只有尝试了才知道适不适合，只有切身体会才能辨别谁是谁非，本文并非推崇一定要前后端分离，而是希望大家在合适的应用场景下去尝试前后端分离，在丰富经验的同时或许也会擦出火花。

原创文章，转载请注明来自一个萝卜一个坑 -博客园[http://www.cnblogs.com/luozhihao]

本文地址：http://www.cnblogs.com/luozhihao/p/5761515.html

本文同步发表于：https://segmentfault.com/a/1190000006240370

14楼莱布尼茨: 纯粹的前后端分离，即前端html，通过ajax请求后端接口，这是有利有弊的。好处楼主已经说了，弊端评论里有人也提及，主要是后端苦于提供比以往多很多的接口，大部分公司都会陷入接口杂乱或代码执行效率低下的局面，而前端会觉得后端只要给接口，原本一些业务逻辑都向前端转移了，有时候也会出现一些扯皮的现象。工作量未必比之前的嵌入方式少。，我们现在使用mvc，前端人员必须掌握vs的使用和razor语法，后端人员除提供接口外，可以其它形式返回数据到前端，比如在action中直接返回数据。没有后端逻辑嵌入到页面中的情况，前端依旧关注数据的展现和前端逻辑，算是一种平衡吧。，重前端轻后端是趋势，前端人员的技术要求也要相应调整。

13楼饭溢出: 要为有想法的赞一个。，类似文章Web 研发模式演变，另外，我想请教一下，AJAX或者其他其他框架的使用，如何保证网站的SEO？

12楼烧点饭: 我也是这么做的，后端开放API接口，APP用的Ionic，只管调用接口，后来又用到vue.js做手机网页，无论前端还是后台都得我自己搞定。

11楼灵雨飘零: 前后端分离很有必要！

10楼京山游侠: 写得非常好。希望大家都点一下推荐。，我非常赞同楼主的思想，我现在也越来越发现前后端分离的好处。，，前后端分离，不是说一定要前端和后端两个程序员，一个全栈工程师也可以做。只是在做的时候，不要把前端代码和后端代码纠缠在一起，后端只负责提供数据，前端只负责呈现，这样更容易维护，增加开发效率。这只是一个思路的改变。，，另外对于SEO和SPA，SPA确实不利于SEO，但是并不是所有的应用都需要写成SPA，和用户交互比较多的写成SPA，数据展示比较多的写成单独的页面。SEO主要针对的也是数据展示，而不是用户交互。这并不冲突。

9楼Akon_Coder: 请问下，你们做前后端分离，前端主要用到了哪些技术？

8楼tony_: 能否讲一下前后端分离带来的弊端，以及如何缓解的？，我在实践过程中主要是在联调过程中出现的问题，沟通成本非常高。，另外维护起来通常需要一前一后同时处理才能进行维护。，不知博主在这两方面是如何实践的。，不吝赐教

7楼HansonWu: 就是单页应用。现在的主流开发方式啦。

6楼山中草: 从前端的角度看，想法很美好。不过后端要支撑各种变化的接口，需要很强大的架构支持

5楼—阿辉: 最近正在做前后端分离，给我的感受是很颠覆，开发人员可以更加专注的干自己的工作。

4楼每日懂一点: 前后端分离之后，后端应该微服务化，这样后端的功能才能更好地复用。但这样的话会存在一个问题，前端在做数据展示的时候需要后端多个接口，这样会产生多次的http请求，对页面的响应速度有一定影响。

3楼田园里的蟋蟀: 非常好的一篇文章。，，我最近也和前端同事在讨论这个问题，比如有时候前端写好页面给后端了，然后后端把这些页面拆分成很多的views，有时候还会在这些view中写一些c#代码，突然有一天前端页面的样式出错了，但前端那里并没有问题，然后后端把前端叫过来，说你在我这里调吧，因为你没有后端的调试环境，然后前端就会很不爽，然后。。。你懂的！，，其实理想的情况，就像你说的那样，前端写好页面，关于动态数据都用ajax的方式进行加载，这些动态数据在前端那里先mock出来，但数据的格式要有一定的规范，前端弄好这些之后，后端不能去修改这些页面，而是给前端一些数据接口，前端直接把接口替换掉mock就行了，如果页面出了问题，前端直接修复就行了，各司其职的工作效率会非常高。，，总的来说，就是前端和后端要有一定的规范和接口，彼此不干预对方的工作内容（比如后端在前端写好的页面里面写后端代码）。

2楼牛腩: 问题是公司的“前端”，其实是设计师，他们只会设计 PSD后然后把PSD转为HTML扔给我们。HTML中一点JS都无！！！

1楼一他他: 用户登陆之后，如何确保数据安全呢？？