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

52

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

尝试与改变

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

把流程从

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

心得与体会

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

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

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

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

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

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

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

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

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

本文地址:https://segmentfault.com/a/11...
博客园:http://www.cnblogs.com/luozhi...


如果觉得我的文章对你有用,请随意赞赏

你可能感兴趣的

35 条评论
SFLYQ · 2016年08月14日

你说的这个前后端分离只是说后端不需要在视图写服务端脚本绑定数据渲染HTML,后端只提供API接口前端通过ajax和mvvm框架渲染DOM。
这个其实不能达到真正的前后端分离,现在比较流行的都是前端使用php,或者nodejs,请求后端提供的API,然后绑定视图或者提供接口给前台使用,直接绑定视图的好处是客户端接收到响应后就可以直接渲染不需要异步加载,用户体验好。前端在请求后端API后进行一些逻辑处理再返回API给前台可以将一些逻辑操作由前端自己来控制。后端只需要提供数据API即可,不需要在考虑为了前端不同的业务需求而去做数据字段的特殊逻辑等,职责更佳清晰,后端只需要专注数据层面。

+3 回复

0

是不是就是PHP做中间业务层,柔和多个接口,减少页面请求?

程斌 · 2017年07月04日
0

这是分离后可以达到的一种效果

SFLYQ · 2017年07月19日
lightman217 · 2016年08月16日

前端渲染性能非常好,但有一个比较大的问题是对SEO不友好,prerender是对google很好,但是百度依然不友好,不好做seo优化。但是很多网站比如电商,网上服务还是需要很好的seo优化。Ajax的请求返回数据,爬虫来讲并没有出发。关于这个大家有没有解决方案呢。

+2 回复

IvenZhang · 2016年08月16日

前后端分离工作的话,其实会有一个问题:产生比较多的请求链接。前端大部分都过AJAX来获取数据,可能就会有这个问题。例如:一个页面有好几个展示数据模块,后台做接口时一般是一个模块一个AJAX吧,但其实有很多项目都可以一个AJAX请求链接就可以把数据获取出来,这样既减少http请求,也减少后台代码对数据库链接的次数。

+1 回复

Jekey · 2016年08月17日

关键是你要有牛逼的前端

+1 回复

mage · 2017年02月23日

说到心坎里了,由后台控制路由实在太受苦了

+1 回复

4ever · 2016年08月12日

支持,公司最开始也没前端,都是后台搞后台兼前端,后来来了个新主管,他就要求我们前后端分离,还给我们一套前后端的协议书,然后我就开始了前端的工作,爽

回复

劳卜 作者 · 2016年08月12日

有一个优秀的leader就会有一个优秀的团队

回复

二次元李健 · 2016年08月12日

前后端分离的事我们公司也推行了快一年多了,从nginx代理(解决跨域问题)加Ajax,到后面的nodejs加前端mvvm框架。谁用谁知道,效率提高很多

回复

liangzp · 2016年08月12日

我比较好奇,这样前后端分离后。前端与后端是怎么协同本地开发的?
是前端开发人员也要在本地部署后端的开发环境吗?
还是真的做到前后端彻底分离,前端交互使用node.js与后端rest api交互?

回复

0

同问

agrass · 2018年04月08日
july_L · 2016年08月12日

前后端只要约定请求接口的数据格式就可以了,后端提供接口,前端ajax取数据不需要配置后端环境。

回复

huanghe2016 · 2016年08月13日

分离之后,页面由谁渲染?

回复

劳卜 作者 · 2016年08月13日

由前端渲染

回复

billowqiu · 2016年08月14日

“现在比较流行的都是前端使用php,或者nodejs,请求后端提供的API”这段话看的不太懂。。。

回复

0

用node 写中间件 去请求php数据

sunsmell · 2017年11月22日
魔法少年 · 2016年08月14日

其实两种并没有什么职责不清的问题,本质上来说区别不大,只是业务功能是放在所谓的前端做还是后端做。业界常用的方法其实主要还是几家大公司的用法,也不见得适合所有的公司。其实我建议的还是前端只管渲染层问题。不过也要看业务,前端只管渲染层比较适合SPA这一类的业务。

回复

andot · 2016年08月16日

现在最好的前后端分离方式是使用 hprose 来发布服务,前端不管是网页,手机、平板的 app,还是 PC 客户端,都可以直接调用,通过这种方式分离,比使用 RESTful API 要方便的多。

回复

叫我布鲁斯 · 2016年08月17日

其实百度也是支持prerender的,可以看这个,首页的快照是渲染好的,只是样式因为有域名白名单所以没有。

回复

玉蝴蝶 · 2016年08月17日

前后端分离简直不要太爽

回复

tolerious · 2016年08月17日

前段只需要看结构文档,也就是API文档就好了,API文档后台可以用工具生成出来、

回复

liangzp · 2016年08月17日

那前端人员怎么部署开发的,

回复

tangsuan007 · 2016年08月20日

现在就是尝试采用这种模式开发的

回复

载入中...