传统web开发如何进行前后端分离,或者说是否有必要进行前后端分离

这里希望做到的分离是:

  1. 前端独立开发,独立发布
  2. 必要的页面实现服务器端渲染,
  3. 浏览器兼容常规版本,例如ie8+

想知道有没有好的方案,或者是否有必要这样做

阅读 7.7k
7 个回答

前后端分离、服务端渲染,都有它的好处和必要性,当然也有适用场景,之前回答过类似的问题,原问题传送门《讨论一下前端开发模式

原问题如下:

目前有两种方案:
  1. node作为前端服务渲染页面,页面写的是后端模板。用node跟服务器php进行交互。
  2. node+react,node作为服务端只提供服务,页面由客户端渲染,交互逻辑也是写在react组件中,根据react的0DOM操作会提高页面的渲染速度。

请大家各抒己见,来探讨一下这两种开发模式哪种比较好,请说出原因。

回答如下:

两种方式各有适应场景,下面就简单说下各自的优缺点适用场景

方式一

node作为前端服务渲染页面,页面写的是后端模板。用node跟服务器php进行交互。

优点

  1. 对页面SEO友好:页面在服务端渲染好,对SEO比较有利。
  2. 首屏呈现较快:node、php交互,假设部署在同一台机器,属于本地通信,速度快,相应的 获取数据-> 渲染页面 -> 返回页面的时间相对方案二要快。

缺点

  1. 两次实现:同样的渲染逻辑,可能需要在服务端、浏览器端分别实现一次。
  2. 服务质量可靠性更高:服务端逻辑相对重了,质量可靠性保障要求就上去了。

适用场景:比如新闻门户、博客等。

方式二

node+react,node作为服务端只提供服务,页面由客户端渲染,交互逻辑也是写在react组件中,根据react的0DOM操作会提高页面的渲染速度。

优点

  1. 前后端解耦:服务端负责提供数据,客户端负责视图渲染,可维护性更强。
  2. 无须两次实现:上面已提及,不赘述。至于react本身带来的好处这里不展开。

缺点

  1. 对SEO不友好:这种方案,返回前端的页面大部分时候只是个骨架,内容尚未填充,因此,SEO效果不会很好。
  2. 首屏呈现速度较慢:react是个大家伙,此外,加载js(包括react)-> 拉取数据 -> 渲染组件 相比方案一,速度一般会较慢,因为网络来回比较多。

适用场景:重业务操作、交互较多的站点。比如管理后台、富客户端应用。

前后端分离哪有你想那么复杂
后台写好接口
前台根据接口实现页面不就完了么
至于兼容性 ,根据产品需求来啊。
前后台分离哪有那么高大上,只是各自提升两端的效率罢了

前后端分离确实是一个比较不太好处理的问题,关于这点,阿里的同学有在研究,附上链接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.前后分离是主流,相比以往服务器生成页面,前端请求后端的模式相比,前端自主请求的方式更加高效。

当然还有很多优点,既然大家都这样干肯定是有它的道理在嗯。

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题