这里希望做到的分离是:
- 前端独立开发,独立发布
- 必要的页面实现服务器端渲染,
- 浏览器兼容常规版本,例如ie8+
想知道有没有好的方案,或者是否有必要这样做
这里希望做到的分离是:
想知道有没有好的方案,或者是否有必要这样做
前后端分离确实是一个比较不太好处理的问题,关于这点,阿里的同学有在研究,附上链接http://blog.jobbole.com/65513/
我说下我们公司的前后端分离方案吧
要做到前后端分离的话,那么必须要求前端开发人员将数据加载的工作承接过来,后端的同学只负责提供接口以及后端业务实现,可以客户端以及前端共用一套接口
我们的前端页面是纯静态的html文件,通过ajax调用接口获取数据后,使用vue框架进行渲染
vue提供了一套模板渲染的方式,使用方法类似jsp,php这样的模板引擎,速度还算理想,可以尝试一下看看。
另外,前端人员尽量功能做到前端工程化,如果纯html进行编写的话,很多后端类似jsp的特性会满足不了,比如include页面,但是前端可以使用gulp进行前端的工程化处理,能够解决一些px转rem,图片压缩,文件include等一些提升效率的方案。
这样一来前端的部署就简单多了,而且本地不需要启动服务器,打开页面就可开发调试
至于线上部署,完全可以部署到nginx下面。
简单回答一下吧,我赞成 @ypinchina 的回答,前后端分离并不是什么高大上的事情。
其实前后端分离的本质就是谁去渲染页面,传统的方式是后台渲染数据,甚至后台也会用 ajax 调接口处理数据。
分离的话就是前端渲染数据,所以只要用一个模板引擎就可以了,比如 Handlebars、ArtTemplate 等,这和 jsp、php 写页面的方式非常类似,不过这里有一个页面缓存的问题。
很多人有一个误区,认为前后端分离必须使用框架,其实两者并没有什么必然的关系,前后端分离并不一定需要使用框架,而使用框架也不等于前后端分离。
我觉得还是有必要分,业务简单还好说,业务复杂起来,一个是可能会相互依赖或者相互扯皮,另一个是并发之类的。可以考虑用中台(阿里的叫法?),就是用node或者php这样的轻后台处理调用后台接口或者是拉页面数据这样的活,进一步的话可以尝试php挂模板或者直接搞vue、react这类MVVM配合node搞同构,这样把渲染放到后端,就没必要等页面框架出来后再拉数据渲染一遍,提高了效率降低了用户等待(纯用户信息页连ajax库都可以省了),也直接避开了跨域的坑,另外后台细节也一并藏起来了(比如都用阿里云的话,直接内网通信就得),数据处理放在中台,前台可以直接调整想要的东西,跟后台也少了对接复杂度,比纯粹用HTML+CSS+JS要划算很多。
个人觉得前后端分离是一个未来趋势。ajax和诞生使前端工作从原始社会的时期进入了农业社会,而node的诞生使前端进入了工业化时期,前端不用再依靠后端才能实现一个页面的渲染,前端承接了后端人员的页面渲染逻辑任务,自成一个项目,能更大的实现一个前端项目的复用,以及更快速的把一个网站新型UI的更替,双方工作人员能更加明确双方的工作任务,双方的工作可以同时进行不必相互牵制与扯皮。
不过我同事说了一个有趣的真理::
前后端分离只是为了更好的压榨程序员的劳动力。本来前后端一起开发就很影响开发效率,分离开就各干各的,项目就可以并行开发,争取早上线,早挣钱!
最后附上作者张亚涛的文章:https://segmentfault.com/a/11...
1.有利于工作分模块化,形成流水线,毕竟术业有专攻
2.前后分离是主流,相比以往服务器生成页面,前端请求后端的模式相比,前端自主请求的方式更加高效。
当然还有很多优点,既然大家都这样干肯定是有它的道理在嗯。
10 回答11.1k 阅读
6 回答3k 阅读
5 回答4.8k 阅读✓ 已解决
4 回答3.1k 阅读✓ 已解决
2 回答2.6k 阅读✓ 已解决
3 回答5.1k 阅读✓ 已解决
3 回答1.8k 阅读✓ 已解决
前后端分离、服务端渲染,都有它的好处和必要性,当然也有适用场景,之前回答过类似的问题,原问题传送门《讨论一下前端开发模式》
原问题如下:
请大家各抒己见,来探讨一下这两种开发模式哪种比较好,请说出原因。
回答如下:
两种方式各有适应场景,下面就简单说下各自的
优缺点
、适用场景
。方式一
优点:
获取数据-> 渲染页面 -> 返回页面
的时间相对方案二要快。缺点:
适用场景:比如新闻门户、博客等。
方式二
优点:
缺点:
加载js(包括react)-> 拉取数据 -> 渲染组件
相比方案一,速度一般会较慢,因为网络来回比较多。适用场景:重业务操作、交互较多的站点。比如管理后台、富客户端应用。