1
tomwan 2014-11-25 11:27:03 +08:00 1
没那么大规模的话,这样搞是在折腾
|
2
ZackYang 2014-11-25 11:36:08 +08:00
折腾...让我想起我个人网站都是前后端分离...
主站zackyang.com在github page 服务端api.zackyang.com在AWS EC2 nginx反向代理的node上 正准备把照片使用的img.zackyang.com放到七牛去 |
4
thonatos OP @ZackYang
放在github上的主战显然是静态站喽,然后呢, 你的这种是较为类似ng的方式(也就是ajax方式)直接请求服务端数据的, 这样的分离,很大程度上是受限于自身网络情况了。 采用顶楼的图二的方式,数据请求是放在内网或者同一服务器,数据请求的速度显然是要更高一点的吧? 那么,问题来了: 直接展示的内容显然是通过node来render了,ajax的内容....又是受限于网络了...(eggTeng!) ..只是讨论,畅所欲言喽~ |
5
liangdi 2014-11-25 12:12:16 +08:00
我们现在也是在尝试
前端完全的静态资源,通过ajax(ng) 请求数据 后端只提供api接口(包括后台管理模块也是 独立的静态前端) |
6
juicy 2014-11-25 12:28:41 +08:00
@liangdi 我们公司采用这种形式快三年了,这几年最大的感受就是,前端工作量巨大,很多时候后端的一些工作都转嫁给前端。我想说这是一项造福后端的伟大创想,恩!
|
7
liangdi 2014-11-25 12:31:48 +08:00 via Android
@juicy 哈哈。你说的对。前端工作量变大了。但是相比以前。需要和后端或者自己处理 和后端有些打交道的view。这种方式变得更灵活了。目前我们正在往这方面重构。如遇到问题。到时候可以向你请教了
|
8
caixiexin 2014-11-25 12:35:16 +08:00
手头项目已经这么干了1年,项目用java做后端,提供rest接口,Html5+css+js前端,也有php单纯做前端。说说体会:
好处就是前后端分工明确,专注自己的模块,干活效率高。单元测试,优化什么的都能分开做 ps:我已经1年没写过view了。。 缺点也很明显:当人手不足时,忽然把后端人员调到前端,完全没办法动手(当初看到backbone和bootstrap结合的前端时,差点跪了)。。反之亦然。 |
9
caixiexin 2014-11-25 12:39:32 +08:00
@juicy 我也觉得前端工作多了。。不过后来想想,其实是我们做后端的只考虑功能实现,偷懒不去优化接口,做详细的单元测试才这样(我经常接口写完没怎么测就丢给前端用,用出了问题再改,这样其实很不好= =)。后端要做的事其实也很多,不过用户很多反馈都是从前端得出的,所以当后端功能做完后,很少会碰到需求变更或优化。
|
10
thonatos OP |
11
Arrowing 2014-11-25 12:42:18 +08:00
我也用这种方式做了一年
我是做前端的 前端的工作量要 X 2 不过分工确实挺明确的,后端开发API就好了。 |
14
liangdi 2014-11-25 12:46:43 +08:00 via Android
@thonatos 使用angular等mvvm的框架,很容易实现你想要的东西。上手后 前端开发还是比较爽的。依赖,以及模块化都可以搞
|
16
thonatos OP @caixiexin
不知道你们对于ng的看法,但是我非常喜欢ng的实现方式,但是ng对SEO不够友好。 现在要用这样的方式的话, 将ng的controller重新拉回到nodejs, 将ng的数据绑定回归到nodejs的模板引擎,当然,不是完全的替代; 有些地方,还是会采用mvvm模式或者数据双向绑定的方法来实现,毕竟可以降低劳动量。 我们过去的模式职责不够明确,前端对后端的依赖过大(我是指非类SPA项目),现在这样,重新定义前后端的职责和权限,前端的自由度是增加了的,可控制性也更大了;后端,也能更多的关心业务逻辑,这样更好一些吧。 |
20
thonatos OP |
21
liangdi 2014-11-25 12:54:28 +08:00 via Android
前后端分离的另外一个好处是当你要增加app客户端的时候就很轻松了
|
22
thonatos OP |
24
juicy 2014-11-25 13:05:28 +08:00
作为一个reactjs拥护者,SEO毫无压力!
|
25
yakczh 2014-11-25 13:11:54 +08:00
如果是post提交有事务的操作呢,比如支付什么的
|
26
learnshare 2014-11-25 13:19:51 +08:00
把之前的 CS 模式延续到 BS 上,都是重前轻后的方式,客户端/前端多一些工作量,但后端简单不少
|
27
blue7wings 2014-11-25 13:47:41 +08:00
想过这个问题,想把ThinkPHP替换为Laravel。有没有这方面的书,或例子?跪求LZ推荐下,想深入的学习瞎。。。
|
28
yun77op 2014-11-25 14:41:38 +08:00
我们这边有个工具可以把freemarker模板结合伪数据生产html,并不需要跑整个工程(特别是前期后端都没准备好的情况下),这里就要求前端要熟悉后端的view。
|
29
fundon 2014-11-25 14:44:10 +08:00
|
30
dong3580 2014-11-25 14:48:13 +08:00
正如我正在做的项目:
前端 ajax 前端完全的Html5+css+js 后端 MVC 生成json的api 前后端完全分离,分别部署,安卓/水果端 也用这个api,公用一套Api,如果以后改语言,也行,前端无需变动,手机端也不需要变动,只需要重新做后端。 如果以后数据量大了卡了,只需要优化后端即可。 |
31
thonatos OP @yakczh
关于post什么的,其实并不影响业务系统,模块的分类并没将业务分离出去,所以,还是原来的操作。 @learnshare 嗯,平衡,更合理的职责划分,不过对前端的要求略有增加,但问题应该不大,只是VC两部分嘛 @yun77op 嗯嗯,我考虑下我们这里要不要这样做哦~ @fundon 谢谢~ |
32
thonatos OP @dong3580
是的,我们这么想这样做的根本目的也是为了以后不会相互影响,当业务量增大的时候,完全可以用负载均衡服务器将请求转发过去,当然,还是要做一些优化处理;最想用的地方在于,后端的服务器如果是集群了,那么语言就不限制了,甚至于说,未来根据需要,后端集群根据业务使用完全不同的语言也是可行的。 |
33
thonatos OP @blue7wings
其实换什么不用紧,要这么做就是为了解决后端语言的问题,使得各种语言的使用不影响前端的统一,换言之,前端只需要做一次,后端随便你怎么换,我只要知道接口就行了,其他的,前端不用再去关心了~ |
34
chx007 2014-11-25 15:28:56 +08:00
我们之前的前后端分离,模板渲染全部在前端完成,后端提供RESTful接口让前端用XHR来加载。这会导致`空白首屏`等待问题。
为解决这个问题,我们现在尝试在前后端之间加一个以node开发的中间层,用来渲染首屏输出,而后续的界面上数据刷新,还是由前端XHR后端数据后在浏览中进行模板渲染输出。这里面有个问题是首屏输出与后续界面上数据刷新,在代码逻辑上其实是一致的。所以就设想尽可能让每个功能组件在Node和浏览器端都能运行。找来找去还是觉得React更适合做这样的事情,而跟后端RESTful打交道,可以用superagent,因为它将XHR和node上的http.ClientRequest封装成统一的接口。 |
35
learnshare 2014-11-25 16:09:25 +08:00
@chx007 首页白屏的问题,加一个 loading 动画就好了...
或者首屏的资源尽量压缩减少,最好首屏的资源 HTML/JS/CSS 各有一个,HTML 资源附加一些内容进去。当然,大规模的应用资源加载量不容易控制。 昨天看到朵唯新机的页面,200 多张图,18M 多资源,加载了三分半。 |
36
lygmqkl 2014-11-25 16:53:30 +08:00
其实前后端分离设计的关键在于架构,并不在代码层面上, 国内的伪RESTful 架构太多,如果有一个牛B的架构师,团队最少可以减肥30%,想想少了30%的人员和沟通,开发效率要多高? 成本要节约多少?
但是很不幸国内架构师好像不是那么热。 PS: 最近在给一个知名xx做一套架构,用的就是RESTful 的api,我都是采用非常简单的逻辑,但是目前来看,代码实现的难度 和 大家开发的效率都得到了有效的保证,当然运行效率也是很高的,毕竟RESTful 天生的statelessness 就已经足够优秀了。 |
37
tojoevan 2014-11-25 16:59:33 +08:00
不错哦,支持哦
|
39
thonatos OP |
40
boom11235 2014-11-25 17:59:15 +08:00
我聊聊我的想法:(仅作为一个小小前端工程师)
1)不应该因为技术而技术,采用某种技术方案一定是在它可以帮助你解决一些需求的前提下,看清楚前后端分离给现有团队带来的好处和麻烦是很重要的。 2)作为前端工程师来说,node层的加入,提高了自由度,可以更多方面地handle交互相关的东西,但是需要知识层次需要比原有的前端知识更深入到http,网络等。 3)实践的方式,会因实际业务和团队而千差万别,SPA如果适合业务和团队的话个人感觉是较好的实践,前端承载的相对会少也会舒服一些。其次,选择中间node的一层,那么前端需要承载起后端开发的一些东西,或者需要node工程师(如果是web,实际上我不支持node工程师,而是更加优秀的前端,除非是专业性的一些东西,如游戏后端引擎等,因为node工程师即加多了一层,沟通成本,人员成本都大了),现有的node已经可以较好支撑起这一块了。再其次,工具,我认为前后端分离更多着重在职责分离,以及降低沟通成本,提高独立开发可行性,虚拟后端mock以及服务的工具,可以让前后端都独立开发,沟通好交叉部分的数据结构即可,同时也方便做相关测试。 |
43
thonatos OP @boom11235
非常赞同你的看法,职责的分离以及前端自由度的提升是试验的动力之一(二),同时我也不认为让前端熟悉一部分后端的内容是压力,相反,更该是能力的提升,所谓全栈的说法不是很认同,做前端,又同时能对其他内容有所涉猎的能更好的发挥自己的价值,仅仅做demo,很好,但不是最好。 |
44
thonatos OP @ZackYang
进入白屏这个问题,是我太偏激(见谅),这个,准确来说,应该是无解的……(试着将网速限制到足够低,必然还是会出现),即使采用Bigpipe的方式,也依然是不能解决的,这个话题略过吧,sorry |
45
lygmqkl 2014-11-25 19:19:57 +08:00
@thonatos 不知道你说的通讯效率是什么? 我用的是php脚本来搭建后台,一次请求包含所有的信息,对应服务器返回需要的json 数据,不觉得效率上会有什么问题啊
PS: 服务器组成是 6台 web + 2 db |
46
thonatos OP |
47
lygmqkl 2014-11-25 20:07:15 +08:00
@thonatos 耗时 如果条件相同的情况下,应该是不相上下,甚至可能会多损耗5%在传输上,因为对比传统的session结构,request header里要包含的东西显然多了很多,但是这个损耗还回来的是,你可以同时有10台web服务器响应,100个用户的请求,每台服务器处理10个,而且随机选择服务器就可以,因为每一台服务器对相同的request header 返回是一样的。
稳定性应该是提升了的,当然是在请求量巨大的场景下。 请特别注意,在RESTful架构下,缓存更多的是做在客户端,即js代码里,一旦缓存了,请求都不会发送,只要设计的足够好,还是很强悍的。 |
48
otakustay 2014-11-25 20:54:44 +08:00
1. 阿里的前后端分离有它特殊的时代背景,比如前端想要的接口和后端想提供的对不上之类的
2. 你的第2张图里的后端是啥语言,如果不是NodeJS的话,左边那个NodeJS也没必要吧,和后端语言保持一致不是挺好的吗?这个NodeJS放在这的意义是啥 3. NodeJS不能算在前端里吧,这里的分界线很不明确? |
49
hitsmaxft 2014-11-25 21:04:17 +08:00
前后端分离的最大驱动力是团队拆分.. 这不是笑话. 业务团队和ued团队不在一个队伍里, 带来的协作问题不是一点两点能讲完的..
前后端分离倒不是最核心的目的, 而是要分清楚 模型, 业务, 和模板的开发归属. 真正原因, 是在现有的协作分工模式下, 最大限度地解放生产力... |
50
crossmaya 2014-11-25 21:16:38 +08:00
我不知道你这个php和java在这里做什么用,分离不就是统一业务系统吗,后端nginx已经把事情做完了,你这php和java在这里的意思是提供动态内容输出?还是只作为一个入口。。
|
52
thonatos OP @otakustay
1.应用分具体场景而定,阿里的模式也不全是因为“对不上”吧 2.这里主张的前后端分离,换言之是重新定义了前后端的范畴,和传统的前端定义有区别,显然也就需要其他来做后端了,语言一致只是相对而言,并非全部一致,比如多台服务器的时候,你也许能理解这样的好处。 3.仔细看图2,你应该大体能理解这里——前后端的概念。 @crossmaya 你不知道的原因在于你对这里所说的前后端理解上的偏差,前端不只是页面(css/html/js),前端应该是与用户交互的部分,换言之,ios/android的客户端(app),也可以理解为前端;后端是指逻辑和业务系统,比如说进行数据运算,比如说是持续的数据处理什么的。 仔细看图,应该能明白我这里的java和php只是泛指,也可以是c,也可以是go,或者python等等,他是指的整个项目的一个部分,显然动态内容的输出了,内容的输出交给nodejs来做的,可以是静态,也可以是动态,甚至说,可以是cdn。 |
53
thonatos OP @hitsmaxft
嗯,团队合作的时候,分离的确很便利,比如说我当前的开发往往需要后端支持: 我们后端使用了redis,而我本地是不具有redis的,另外一些具体的配置,也不可能完全复制到本地,每次测试,往往需要我push,后端pull,测试反馈bug,重复上述步骤,很麻烦。 如果分离了,那么我负责页面(包含controller,view),model那边利用接口,可以轻松的实现现有的模式,只要后端保证model层的稳定即可,当然了,有人可能会说我们可以修改现在的模式,让我本地可以访问redis之类的,但那终归不是最好的解决方法,对吧? 扩展下,我的本地环境,其实就是充当了负载均衡控制的web服务器之一(web服务器是多台,例如5),同时业务服务器有2台,那么,web是独立的,他可以自主部署自主测试,业务那么不需要重复做”无用功“了。 这样才是真正的解放生产力么(⊙_⊙)?,前端学点简单的VC算什么难度~~~~对吧~ |
54
maxiujun 2014-11-25 22:09:41 +08:00 via iPad
我在一家专门提供外汇交易平台解决方案的公司,最近一年都在用ember.js做类似的工作,效果不错,我觉得对于页面上复杂逻辑的实现,ember,angular 帮助非常大。同时后台用spring mvc 的rest借口也同样有我一个人完成,这样就可以平衡前和后端了。
|
55
thonatos OP @maxiujun
嗯嗯,一个人做的话...确实是完全自主发挥了,我的主管大人直接发话了: “统计哪里,就当你的试验田,随便你怎么搞~” 这样的分离也没有要完全放弃ember,angular的说法了,主要是如我附言那边写到的原因喽~ |
56
maxiujun 2014-11-25 22:23:49 +08:00 via iPad
其实关键的问题就是前端和后端的界限在哪里,我们这的界限就在java的接口上,所以我们这么做也就好理解了。
另外,做了这么多实践,感觉,只要把前端的工具链(Grunt,bower 等)弄熟练,主题里面提到的“分离”就水到渠成了。 |
57
thonatos OP @maxiujun
讨论再多,也只是为了提高生产力嘛~ 最后做的东西即使一样多,但是中间环节的减少,在团队协作中,确实是巨大的提升。 (对于个人开发者来说...基本可以认为是一样的,至少过去我做东西,从来都不会考虑这个.) 前端和后端的界限,我认为是职能,或者说职责,减少无用功,这样定下的界限,更好一些。 |
58
exodia 2014-11-25 23:24:58 +08:00 3
好无聊,过来练习下写作和表达能力。
首先,我觉得不要扯性能方面的问题,性能对于绝大多数非首页场景都不会是瓶颈。真要追求极致性能,就像淘宝首页一样,写成静态 html好了。 解决前后端分离的问题,目前大概有以下几种方案: 1. 前端写后端模板 1)前端和后端的模板是不一致的,比如前端可能用 Hanldebars,后端 java 经常用velocity,php 用 smarty,都由前端一起维护。比较恶心的问题在于,公司大了,部门多了,业务线多起来了,可能技术选型都不一样,比如有的业务线用 php,有的用 java,还有的用 python,他们的模板引擎可能都不一致,一是碎片语言实在太多了,更严重的是阻碍组件的复用,比如淘宝的通用吊顶和吊尾以及登录框是可以全站复用的,但之前用 java 写的,如果有的业务线用 php 咋办?于是他们对这些组件进行前端组件的静态化处理,即这些组件变成了 html+css+js的片段给其他业务线去用,数据请求通过 ajax 去做;但这些组件的一个特点是,依赖后端的动态数据较少,比如吊顶只是简单的一个登录信息请求即可,不适合需要大规模的后端查询页面。 因为1)的问题,于是有了下面的 2) 2.1) 前后端统一模板,模板语言嘛,用不同的语言都写个引擎就好了嘛,比如后端 nodejs 用 jade,咱前端也用 jade,嫌慢,咱先编译好。这个我还没找到比较大型的案例,我自己做着玩玩的时候用过。 2.2)有人觉得每个语言都要为一个模板语法写一个引擎,维护成本也大,模板语法一更新,所有引擎都要更新,真是去你大爷的- -! 于是呢,linkedin的做法是前后端统一模板为dust(你猜对了,js的模板引擎), 后端在渲染模板的阶段,起个线程跑v8引擎,去做模板渲染。于是成功解决了web组件(前后端都有)复用的问题。 1方案的普及需要有好用的工具提供给前端做开发调试mock等,比如淘宝曾经出了个 vmarket,据说难用所以没然后了。然后,fis 也有针对这个专门做了工具,具体去 fis 主页看好了,最近我在试用他的 java 解决方案,感觉还是比较容易上手的。 2. 前端 mvc(webapp) 感觉不用太多介绍吧,这几年比较火的架构,模板在浏览器渲染(尼玛,你说后端返回渲染好的 html 字符串,艹,这还能叫前后端分离- -!!!!)。 很多人这个方案问题在于seo 和性能。就 seo 来说不是太大问题,比如我从组里同学那获知的用个 phantomjs 渲染出页面丢给 robot 就好了,以及 google 是有针对 ajax 页面做索引的。 再说说性能,linkein 不用前端 mvc 的一个很重要原因就是性能,不过人家是因为页面要兼容到 ie7,ie7没有原生的 JSON 提供,解析起来确实是巨慢无比,所以放弃了。我觉得吧,如果你的项目仅需要支持ie9+等现代浏览器,基本可以考虑采用这个方案试试,当然 seo 这块我也没涉及到,不好扯淡,有朋友去试了可以教教我~ 2方案对前端的要求会比1更高些,大规模项目的路由设置,模块切分,mvc 的职责,代码规范,目录结构的组织,都需要有一定功底,否则会玩脱。 这个玩法比较多,框架也很多,angularjs,ext,然后是我们这的一系列组合: https://github.com/ecomfe/er https://github.com/ecomfe/esui https://github.com/ecomfe/oo https://github.com/ecomfe/uioc 打广告就是爽,呵呵呵呵。 3. 加一层中间层 比较火的,淘宝中途岛,比较低调的, fis 的 yogurt。 线上案例,百度音乐移动版,淘宝的对外项目不是太清楚,麻烦知道的同学告知下,内部项目主要是之前的数据平台部门的一些产品:在云端等。 我曾经是这个方案的拥护者,在经历了北京velocity大会的 fis 和淘宝的前后端分离实践分享,前不久d2的支付宝前后端分离实践分享,以及最近自己在搞一个业务线前后端分离的实践后,我现在成为这个方案的反对者。至少我觉得这个方案不适合大多数场景。 我们看看这个方案想要解决的问题: 1) 前端依赖服务端开发环境 2)在服务端View层高度耦合 3)沟通成本高 4)职责不清晰 对于1),可以通过开发优秀的工具去解决,至少 fis 的 jello 还不错。 对于2),不明白这耦合在哪里? 对于3),阿里的场景是前端写html Demo,再丢给后端套,敢问有几个公司这样做? 对于4),我觉得和2)一样,说的太虚了。你要说职责清晰,学学腾讯把 html css 也分出去得了 - -。。 关于 ppt 中说前端 mvc的问题,限于篇幅和精力,我懒得吐槽- -!,@otakustay 可以来试试- -! 再看看这个方案会遇到的问题: 1)学习成本实质是最高的。 天真的以为仅仅是语言没有学习成本? 后端的各种技术,安全,日志,监控,并发,事务,分布式 session,数据库读写分离,确定一般的前端能搞定?阿里经历了多少年,java 发展了多少年才成就了现有这么成熟的体系。 bat 或许能用 nodejs 去玩玩,因为技术的服务化和平台化比较成熟,都会提供服务化的api来用, 比如分布式的 session 访问,你只需要去调接口,不用自己去用 nodejs 实现一套了,再说用户信息,订单信息也是提供接口给你,至于他们怎么做性能调优,安全处理,数据库设计你都不用管。 但是一般的公司能做到这么高度的服务化么? 2)现阶段绝大多数前端水平还跟不上 即便很多前端号称自己会 node,也只是停留在写工具层面。 在 velocity 上,淘宝的分享者(p7)说,他们请了后端的同学帮他们实现 nodejs 的 session 读取框架,我就跪了好嘛,整个淘宝 ued 都找不出一个前端能写这个,你确定有几个前端有这个技术能力去 hold 这种技术? 在阿里也就那些数据平台部的人在这方面比较牛逼了,但是别人一直都是以后端为主,前端为顺手写,起点和一般前端完全不同,现在最多就是挂个前端的 title 在上面。 3)想要解决的问题都可以有更快捷简单的方式去解决 对大多数场景来说,我更推荐1的解决方案,简单快捷,没有太多成本。比较成熟的公司想要做组件化的复用可以参考 linkedin 的方案。 中间层可能只是一个舍近求远的方案。 最后,中间层这个方案给我感觉最多会成为一个,由 nodejs 渲染的模板引擎方案。 当然,我个人倒是蛮希望这个方案能够将前端的总体水平提高一个档次,能够将前端工程师变为工程师。 |
59
HaEx 2014-11-26 00:20:24 +08:00
@exodia 就事实而言,最后的描述的三个问题中,有一个里面没一句话是对的,当然我也不知道您是从哪里打听到的;至于其它的,就不吐槽了...
|
60
exodia 2014-11-26 00:29:19 +08:00
@HaEx 我比较喜欢直接吐槽,这样我可以认识到我的问题,至于你说最后的三个问题,有一个不对,那么我猜你说的是第二个,这个我没有打听,因为这个是我在 velocity 上直接问的清羽,是他说的,至于他说的是不是事实,我只是转发。 数据平台部门在 node 牛逼,这句话我确信没啥问题,当然,可能现在没这个部门了就是,呵呵
|
61
thonatos OP @exodia
看到神仙打架了么这是....(玩笑) 这里开帖子就是为了探讨这个问题,打广告神马的自然是很欢迎了,有更好的解决方案自然无需造轮子了,EFE与淘宝UED的使用场景不同应该是无可非议的了。 webapp方式的解决方案,是我一开始就在用的,甚至于现在还在用(目前还没开始试验淘宝的方式),SEO方面的问题,个人认为不应该是问题,可这个显然依然是问题,至少DU厂的搜索引擎,对Ajax站的支持貌似没Google那么友好(如果有错,还望指导下DU场针对Ajax站的SEO方法) 既然有心情学前端,自然不能仅仅停留在页面仔的范畴,精通另说,最起码要有涉猎,这样的学习成本,是值得付出的,编程语言服务需求,说到底,选择什么还是为了项目本身,在这之外,能让自己能力有所提升,也是一件很开心的事情~ 中间层的方案,V的职能不可否认,C的职能或者可以更进一步抽出? 或者,也许我们可以试试MVC三者的进一步分离? |
62
soulteary 2014-11-26 01:24:37 +08:00
@exodia 这几个问题如果想知道答案,不如发简历来,如果ok,我们还能对半分入职的奖励,2333
如果不发简历的话,那就无责任吐槽加回复一些我所知道无伤大雅的东西吧。 有的业务和实现还是蛮复杂的(历史原因,发展原因,各种其他原因),即使接口化程度好一点,如果你也有做的话,应该明白这点,session这个我刚刚顺手看了一眼代码,似乎苏千大神12年就写了,不过14年又更新了一部分,或许我们说的不是一个事吧... 如果抛开公司业务,我觉得不管是用redis/mysql还是写文件方式来写一个node版本的session rest接口也不用多久,何况团队里好多技术碾压我的前辈... 弱弱吐个槽,朴神很强力吧,但是职级是P6,诶,是不是说明层级不能完全作为你的论点的数据参考了呢..(朴神,我不是故意黑你的...) 第二段同意部分语句,作为团队拖后腿的渣渣从来没敢说自己会node,或许是团队大神封装中间件略赞,或许是小伙伴强力,不管是安全过滤/路由定义/日志调试/数据代理(尤其)都是用的爽的不要不要的,自己专注业务逻辑就可以了,或许你会觉得业务模型简单,但是其实承载的内容真的不少,还有巨量的流量每天帮你跑各种分支(233)... 总之,很多事情不能用简单一概而论,自从用了中间件,大概出活更快了(即使需求和要做的事情更多了),和后面数据接口那边的童鞋只需要约定数据格式就行了(其实还可以更狠点,直接捞数据,不过这样就不是各司其职了),有的时候做事情,互相旺旺贴下接口定义,大家就心照了,多愉快。 对了,好像还有说性能来着,只能说双十一毫无压力,等着看双十二性能图表中~ 比起三天两头开个会,各种约定,最后接口变了,前端模板逻辑甚至业务逻辑要重写代价小的多吧,即使数据源那边变了,我们的改动也不过是nodejs接口层修修改改,做做测试就完事了,不过这样也有个坏处,就是可能前端比后端完成事情的时间点早太多,去投入别的事情了,过段时间要返回来和后端联调(同时其他事情来了,会爽的不要不要的...) 以上,感觉自己title只是前端,连工程师都不是的渣渣吐槽完毕。 --EOF-- |
63
thonatos OP |
64
exodia 2014-11-26 01:48:42 +08:00
@thonatos seo这块,百度做的确实不够好,该黑的还是要黑,就事论事,解决方案文中提到过一个,针对 robot 使用 phantomjs 渲染页面丢过去,我没试过,但理论看着可行,所以我也希望有人尝试一下论证。 另外,也没啥打架不打架,我只是想明白中途岛方案和其他方案相比,到底优势在哪?仅仅是想探讨技术而已,请尽可能的,也尽情的在技术上扇我耳光。。。。所以如果有支持中途岛的同学,我仅仅是想和你们交流下技术方案而已,不要想太多了。
@soulteary 既然你们是中途岛的拥护者,不好好的推广,说说你们的方案对比其他方案的优势,掩着藏着是为何? 既然你们提倡这种模式,又出来做分享,解决别人的困惑,说服别人用你们的东西应该是很乐意才对。 关于你说朴灵强不强,我先放着。。。。我也不是要从层级去论能力,但很多时候,层级确实是和能力挂钩。 你说的什么中间件用起来爽,完全没有去回答我提出的疑问,java 不能有中间件?相信阿里的 java 中间件用起来更爽。 再说你的约定数据格式的问题,前端写后端模板,后端一样可以做到只准备数据。难道其他前后端分离方案就不能愉快了? 说性能,你觉得双十一性能稳定是因为你们用了 node?。。。 最后你的接口变了的问题,其他方案的改动会比你的改动代价大?没记错的话,你们是 java 和 node 在同一台机器部署,如果 node 要重新部署了,java 会需要一起部署不? 你说到了苏千,我和你观点一致,他确实是大牛,但是,他确实是搞后端的啊,呵呵,当然现在转到支付宝做个挂个前端 title,做架构的事嘛。包括大部分好用的 node 中间件,你能给我说说这些作者有几个是前端出身? 而阿里一开始就搞前端的,有几个写出了好用的中间件? 另外,我也是经历了写 html demo,到写前端 mvc,再到现在体验前端维护后端模板的方案,才会有了此次的回帖。我想要的方案很明显是ROI 最好的那个。。 |
65
soulteary 2014-11-26 02:19:11 +08:00
@exodia v2没有打呵欠的emoji很是忧伤。
1.不应该把每个人都看成方案的推销者,我只是愉快使用的用户而已,(这个们字哪来的,别是突然又给我扣个帽子,让我去代表其他人吧,我只能代表自己,以用户身份,233333...) 2.掩藏?哪里来的神理解,来吐个槽而已,本来就没计划说服谁,神马很乐意是你按照自己的情况推理出来的么...另外,业务数据邮件是三令五申提醒过的,如果你不懂的话,请参考自己公司的商业规范和保密协议,如果没有的话,那么这位老板请无视我的这条回复。 3.帖子里说能力层级相关的,和技术方案选型又没啥关系,各种因素混合在一起的结果,纠缠起来没啥营养滴...2333 4.中间件多了去了,不知道为啥前端来个解放生产力的工具就大惊小怪的...你觉得啥爽用啥就好,不用告诉我... 5.你动力和愿景这么大,把简历发来,咱俩对半分奖励不是挺好的么...(该解释的之前吐槽不是说了么,自己不看背景乱嚷嚷,有意思么,你觉得有意思,我也没辙..) 6.性能,好吧,我严谨点,我接触的业务毫无压力...童鞋你神经别蹦的这么紧,太困就睡觉吧... 7.你还真是替这个方案操心,你猜猜? 8.po主分享的ppt的作者不就是纯fe么,不过你纠结大家是做什么的有啥意义,这个争论点可以带来技术的提升还是帮助你快速完成需求?ps:自己cat node_modules/package.json看作者不行么...233 --- @thonatos 下次D2? |
66
thonatos OP |
67
thonatos OP |
68
soulteary 2014-11-26 02:42:41 +08:00
@thonatos SEO的话,这个要分情况讨论的,一个是蜘蛛是否支持异步渲染;google有相关规范,百度未知;针对google可以直接提供接口数据,以供抓取索引;针对百度类型的蜘蛛,可以考虑针对UA或者IP做特殊模板输出,或者服务端代理入口转向特殊url...
特殊模板这里又有一个分支,是神马格式展示,xml/html/micro data/...而这些模板由谁处理...是否要做前后端模板共用,复用... 总之,这个事情应该根据自己业务具体情况具体讨论了...v2上吐槽再多都是空的= = |
69
thonatos OP @soulteary
就是担心针对UA做处理,会被关小黑屋……然后就从一个技术问题转变成一个蛋疼的商讨接洽过程(实现上问题不大),不过说到底,我是倾向于中间件的做法,SPA的模式,终究还是有些小坑的,局部使用MVVM更合理一些(主要针对普通的对外项目,不专门做处理,也是解放劳动力吧,T.T) ……碎觉碎觉,迟到了要扣工资滴,可怜的实习生有木有-_-||,明天搞个demo测试一下,看看效果啦,安喽 |
70
konakona 2014-11-26 05:10:10 +08:00
我觉得这样的架构设计有点意思。
不过你们之前的项目是PHP开发,以ThinkPHP为框架。 现在要改为Nodejs,是不是未免变动太大?这样改动期间如何迭代原有项目的维护工作?如何合理重现原有功能结构等等? |
71
exodia 2014-11-26 09:06:15 +08:00
@soulteary 能解决我的疑问才是真的,逃避技术点疑问,没有重点的回答也没啥必要继续了。我目前对淘宝ued一点兴趣都没,不用啥简历简历的,要解决问题,和要不要去ued 那一点关系都没;我从那出来1年多,在现在这个地方无比爽,就这样,,
|
72
clino 2014-11-26 09:13:53 +08:00
自从用avalonjs以后,已经自然而然这么做了,后端基本上只用提供api,其实这样感觉挺棒的,就是需要用对搜索引擎友好的时候还是用后端模板吧
|
74
hitsmaxft 2014-11-26 10:15:02 +08:00
在淘宝/百度下就不是谈技术问题了, 而是怎么推动百人/千人团队的技术更迭和方案更新了, 而且产品都是千万到亿级别的访问量.
这时候只有技术因素是不够的. 所以不知道上面的有啥好吵的. |
75
mengzhuo 2014-11-26 10:51:36 +08:00 via iPhone
也有为了手机客户端和页面共用一套API而进行前后端分离的
|
76
soulteary 2014-11-26 11:09:20 +08:00
|
77
NearTan 2014-11-26 12:43:51 +08:00
学校项目,也是前后端分离,然后前端跟不上,苦恼中
|
78
thonatos OP @konakona
从长远来说,这样的改动是值得的,尤其是项目建设初期就这样做,更是容易实现。 1.改动期间如何迭代原有项目的维护工作 运行时期其实是多台服务器共存的,改动时期也是如此,那么是后端优先(如现在的php重构开始,完成基本功能,接口的开发),前端完成原有模板的升级(tp的模板,和现在的其实不冲突,可以直接拿来用.T.T,修改下模板输出的边界符即可无缝转换了)。 然后通过ip在入口(nginx)设置路由规则,局部更换到新的服务器,测试运行,测试完成后,全局切换过来就好了。 2.重现原有功能 这里想采用中间件的方案的时候,纳入了java和php两种,我们原有系统本身就是接口类型的,这里在未完全搞定之前,或者说之后,除了session这一块(主要是包含认证相关的部分),需要node完成,类似于业务逻辑,大可以还放在原有的tp上,待完成后再考虑迁移(tp移除认证,服务器集群做成内网,限制外网访问,明白什么意思吧?——好开放有木有。。。什么数据都可以随便拿。。。。T.T) 这是我得想法,有好的意见分享一下喽~ |
79
yolio2003 2014-11-26 18:47:33 +08:00
看完发现结论是:没人分离的聊前后端,哈哈哈
|
83
JamesRuan 2014-11-27 21:22:43 +08:00
说一下我们这边的想法。
首先,这是一个学校项目,而且目前还找不到足够有能力+有兴趣的小伙伴来完成,基本上就我和另一大牛YY中。 传统些,而且成熟些的分离方式是前端写后端模板,后端填数据,浏览器还是取页面。这种方式对一个比较成熟的团队来说更加问题,改造代价小;而优势也是显而易见的。 激进些,就是前端完成渲染,后端传数据,而模板和渲染代码都是静态的,由Web服务器搞定,大量的缓存可以推向前端。这样需要前后端之间定一个API。后端实现这个API,前端使用这个API。这样进一步带来了灵活性:后端可以是不同的平台,很容易扩展到多服务器;前端也可以是多平台。我们的应用有考虑到移动端的支持,默认还是开发一个适配移动端显示的HTML,但是由于API开放,相信以后会有其他的小伙伴有兴趣完成移动端的原生App。 然而这一激进的方案也有比较大的问题:目前API设计(我的主要工作)就是难点,由于业务逻辑有些复杂,单纯使用REST会使得有些业务需要多个API调用才能完成,从而产生原子性问题,需要引入状态,这又与REST的stateless设计冲突。另外,渲染代码和业务逻辑代码都由前端完成,使得前端的要求过高,学生中恐怕会难以找到hold的住的人(现在就是找不到人的状态啊!) 所以,有了第三套方案,即基于node或类似比较“轻”的技术来实现中间层,中间层负责业务逻辑,把多个RESTful的内部API调用转换成单一API的外部API调用,从而减轻传统前端的压力。这样,前中后端分别负责交互、业务、数据,缓存更加推向前端,缓存级别增加,同时系统解耦增加,代码逻辑更加清晰,维护性增加,扩展性大大增强。 但是,这第三套方案需要有两套API,精确定义两套API的转换方式(等于手写一遍业务逻辑),且可能设计过于复杂,具体实现时的编码、调试工作都会增加,我们本来就没几个人,怕是折腾不起这样一个系统。 另外,由于是学校内部项目,没有SEO和带宽方面的要求。 |
84
thonatos OP @JamesRuan
时间也不早了,略困,-_-|| 最近睡眠严重不足,老板看到了请自觉涨工资啊! (╮(╯▽╰)╭,要真看到估计要扣……) 如果只是讨论分离,最简单省事的估计也就MVVM的方式了,不过,技术啊方案什么的,最终还是要服务于实际项目。 目前已经测试的是中间件的方式,大概一小时之前测试了一下从阿里云拿数据,效果还不错(打错字母那件事……先不讨论了,-_-||)。 时间上几乎没什么区别,毕竟还是类似的方法,不过是从浏览器转到nodejs。 类似职能分离这话就不吧啦吧啦废话了。 现实点的情况是这样,从前接口未变,后端没帮忙部署,我这里很轻松的完成了页面到测试数据到真实数据的全过程,各种参数随意打,想要什么要什么,不要太自由有木有? -_-||,眼镜睁不开了,先睡了,目测要猝死,哎,享年22,大学未毕业,卒。 |
85
HerrDu 2016-03-24 08:49:31 +08:00
最近也在考虑前后端分离的问题,也看了淘宝的中途岛的思路。还是想问一下,把 python 代替 node 做中间层是不是也能达到同样的效果?
还有就是 调用 restful 接口的时候,是怎么解决跨域问题的? 用的是 httpclient 吗? |