这不是一篇纯技术文章,而是一篇分享我我的在先后端分离路上收获的点点滴滴的文章,以此来为准备尝试先后端分离或者想了解先后端分离的童鞋作一个大致的讲解。html
若是你没有尝试过先后端分离的工做流程,那么能够先试想一下这样的流程改变:前端
把流程从
PM:“我要这个功能”
后端:“这个先找前端作个模板”
前端:“模板作完了”
后端:“我来对接一下,这里样式不对”
前端:“我改完了”
后端:“功能交付”
PM:“春节要加这个活动”
后端:“这个先找前端改个模板”
前端:“模板作完了”
后端:“我来对接一下,这里样式不对”
前端:“我改完了”
后端:“功能交付”vue
变成
PM:“我要这个功能”
前端:“我要接口”
后端:“接口完成了”
前端:“我来对接一下,功能交付”
PM:“春节要加这个活动”
前端:“须要增长接口”
后端:“接口完成了”
前端:“我来对接一下,功能交付”web
因而可知,先后端分离的主要概念就是:后台只需提供API接口,前端调用AJAX实现数据呈现。json
做为一名前端开发人员,咱们应该尝试一些新颖的技术,完善每个细节性的问题,不断突破自我。虽然先后端分离已经算不上什么新颖的技术或思路,可是目前不少后台开发人员甚至前端开发人员都没有接触过。后端
据我我的的了解,若是在一个部门里,部门人员全是后台开发人员,前端的一些页面也是由后台人员完成的,那么先后端分离对于他们而言多是一片未知的领域,项目大可能是先后端强耦合的,甚至不存在前端的概念。前端框架
在不重视前端的公司或部门,不了解先后端分离这也无可厚非。在我刚进入一个全是后台开发人员的部门的时候,整个部门就我一个前端,我刚开始的主要职责就是负责项目前端页面的制做和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框架,咱们能够很是快速的定位及发现问题的所在,客户端的问题再也不须要后台人员参与及调试,代码重构及可维护性加强。
一路走来,项目一个接着一个,从一开始的后台控制路由、后台渲染页面到如今的前端控制路由、前端渲染数据,工做流程和方式都发生了很大的变化。每当遇到下面情形的时候,我都会为先后端分离带来的优点而感慨一番:
项目一开始制做前端页面的时候,我再也不须要后台给我配置服务器环境了
项目的前端文件能够在须要调用后台接口的时候丢进服务器就行了,彻底不须要事先放进去
增长一个项目页面须要配置路由的时候再也不须要让后台同事给我加了,本身前端搞定
前端文件里再也不掺杂后台的代码逻辑了,看起来舒服多了
页面跳转比以前更加流畅了,局部渲染局部加载很是快速
页面模板能够重复使用了,前端组件化开发提升了开发效率
等等。面对快速发展的前端,咱们应该去适应其带来的工做方式和流程的改变,目前的先后端分离的工做方式必然是从此的趋势所在,做为一个前端开发人员,咱们应当承担这个普及前端新知识和改变现状的职责。
只有尝试了才知道适不适合,只有切身体会才能辨别谁是谁非,本文并不是推崇必定要先后端分离,而是但愿你们在合适的应用场景下去尝试先后端分离,在丰富经验的同时或许也会擦出火花。