关于前后端分离的一个疑问:什么是前后端不分离?
发布于 6 年前 作者 langlang1234 22510 次浏览 来自 问答

现在炒作的很厉害啊,我自己其实也是稀里糊涂的 我现在做的项目是ExpressJs + Handlebars(hbs),后台服务还是Java,前端只做路由控制和页面渲染 之前看了一位大大的文章,说根本不存在所谓的前后端分离 所以我就想在此开贴,不讨论什么是前后端分离,我只想问:什么是前后端“不”分离? 比如说,难道说用JSP做为模板引擎,就是前后端不分离? 欢迎大家讨论一下这个问题,困扰我蛮久的了!

9 回复

看前后界限在哪呢。

  1. 用node.js做前后分离, 路由还是node这边来处理,去相应不同的页面。
  2. 还有一种前后分离,后端不限语言,只需要提供一个静态 index.html 入口以及 rest api or JSON API, 路由由前端的框架处理。

我的想法比较极端吧大概,我觉得前后端分离应该是后端只提供接口、返回数据(JSON数组、判断用的响应值),前端获取到数据、构建页面。按这个说法的话后端用模板引擎就不算前后端分离了。 然而这样搜索引擎不好爬取或者压根不能爬取啊。

我认为,前后端不应以不能以模板在哪里渲染为依归,而应以工作的职责为界限。 若 node.js 跑在服务端,但也是调用后端提供的 api ,负责用户体验,作基本的数据检测之类,然后渲染 html ,也算是前端。 后端应该是负责数据的处理,包括检测,转化,各种业务逻辑的实现,事务原子性,吞吐,队列,缓存,分布式方面的工作。 也就是前端主要面向用户,而后端主要面向服务器,中间通过API作为桥梁彼此配合工作。 不过现在一般讲前端,多数谈的是在浏览器端作实现。 随着 react 流行,同构也会是很热门的话题,也就在浏览器实现SPA(利用 h5 的 browser history API),然后再在服务端并行地生成 html 以解决 spa 对搜索引擎不友好的问题。但个人认为这种技术听起来美好,做起来必然是很蛋痛的事情!

同样纠结 现在概念太多 具体怎么样 还得慢慢自己探索

在前后端分离的概念出现之前,那时候的项目难道都是前后端不分离的吗? 蛋疼啊!

@klesh 服务端渲染react我看了下文档,是非常蛋痛的事情

天下大势,分久必合,合久必分,无谓纠结。

曾记得在php的世界,从最开始在html里写php代码,然后的所谓smarty模板引擎,再然后,又回到在html里写php(php本身就是最后的模板引擎),再后来,所谓的后端已经不管展示了,只处理业务逻辑。大胆猜想,再后来,后端连业务逻辑都不管了,只管权限验证和数据存取

你可能不懂架构,但你的代码写多了,自然就不自觉的使用了合适的架构。 你可能不懂模式,但你会慢慢发现,你的代码里满满的都是模式。

Web 开发,合久必分,分久必合!

“遥想公瑾当年”,没有框架支撑的时候,什么 JSP,ASP 和 PHP 都是简单的将后端逻辑代码组合成前端 HTML 标签的输出,甚至用后端语言动态生成一些 JavaScript 代码也是经常做的,这也算是前后端融合,只是混乱的融合、牵强的融合、不能自已的融合。前后端代码你中有我,我中有你,生生世世不分离。

后来终于有些人按耐不住了,说这样“缠绵”想离婚,想分财产都做不到呀,结合之前就得把彼此职责分清楚,后端的就干“家务”,前端的就出去“卖脸”,于是前后端终于通过协议彼此联结在一起,通常来说这些协议可以是任何约定好的东西,不过那个时候也就是所谓的 Ajax 啦。这就是所谓的合久必分。

那些年代,有谁会妄想 JavaScript 也能做后台的,估计 15 年前 Gmail 诞生的时候,写 Gmail 的王大锤(大牛)都“万万没想到”,会有个 V8 引擎,之后横空出来一个 Node。JavaScript 能写后台的年代开启以后,自然而然的会令人联想到既然前后端都能用 JS,何必不让同一段代码能兼容不同的 JS 运行时环境:Browser,Node、Java 乃至硬件平台,这样就跟物理学中的大统一理论一样,所有流派都拜倒在 Isomorphic 教下,统一武林,指日可待。这就是分久必合。但明白人都能看出来,这种“合”与十多年前的“合”是大不同的,如果非要选两个词的话,我觉得“组合” VS “融合”可能有些贴切,就像是前后端技术结合以后生出来的小 baby,似像非像,而且还能做同等的事情。

@tim1020 这帖子发的,哈哈!

回到顶部