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

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

尝试与改变

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

把流程从 
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框架，我们可以非常快速的定位及发现问题的所在，客户端的问题不再需要后台人员参与及调试，代码重构及可维护性增强。

心得与体会

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

• 项目一开始制作前端页面的时候，我不再需要后台给我配置服务器环境了

• 项目的前端文件可以在需要调用后台接口的时候丢进服务器就好了，完全不需要事先放进去

• 增加一个项目页面需要配置路由的时候不再需要让后台同事给我加了，自己前端搞定

• 前端文件里不再掺杂后台的代码逻辑了，看起来舒服多了

• 页面跳转比之前更加流畅了，局部渲染局部加载非常快速

• 页面模板可以重复使用了，前端组件化开发提高了开发效率

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

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