New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Web 研发模式演变 #184

Open
lifesinger opened this Issue Jan 13, 2014 · 156 comments

Comments

Projects
None yet
@lifesinger
Owner

lifesinger commented Jan 13, 2014

前不久徐飞写了一篇很好的文章:Web 应用的组件化开发。本文尝试从历史发展角度,说说各种研发模式的优劣。

一、简单明快的早期时代

1

可称之为 Web 1.0 时代,非常适合创业型小项目,不分前后端,经常 3-5 人搞定所有开发。页面由 JSP、PHP 等工程师在服务端生成,浏览器负责展现。基本上是服务端给什么浏览器就展现什么,展现的控制在 Web Server 层。

这种模式的好处是:简单明快,本地起一个 Tomcat 或 Apache 就能开发,调试什么的都还好,只要业务不太复杂。

然而业务总会变复杂,这是好事情,否则很可能就意味着创业失败了。业务的复杂会让 Service 越来越多,参与开发的人员也很可能从几个人快速扩招到几十人。在这种情况下,会遇到一些典型问题:

1、**Service 越来越多,调用关系变复杂,前端搭建本地环境不再是一件简单的事。**考虑团队协作,往往会考虑搭建集中式的开发服务器来解决。这种解决方案对编译型的后端开发来说也许还好,但对前端开发来说并不友好。天哪,我只是想调整下按钮样式,却要本地开发、代码上传、验证生效等好几个步骤。也许习惯了也还好,但开发服务器总是不那么稳定,出问题时往往需要依赖后端开发搞定。看似仅仅是前端开发难以本地化,但这对研发效率的影响其实蛮大。

2、**JSP 等代码的可维护性越来越差。**JSP 非常强大,可以内嵌 Java 代码。这种强大使得前后端的职责不清晰,JSP 变成了一个灰色地带。经常为了赶项目,为了各种紧急需求,会在 JSP 里揉杂大量业务代码。积攒到一定阶段时,往往会带来大量维护成本。

这个时期,为了提高可维护性,可以通过下面的方式实现前端的组件化:

2

理论上,如果大家都能按照最佳实践去书写代码,那么无论是 JSP 还是 PHP,可维护性都不会差。但可维护性更多是工程含义,有时候需要通过限制带来自由,需要某种约定,使得即便是新手也不会写出太糟糕的代码。

**如何让前后端分工更合理高效,如何提高代码的可维护性,在 Web 开发中很重要。**下面我们继续来看,技术架构的演变如何解决这两个问题。

二、后端为主的 MVC 时代

为了降低复杂度,以后端为出发点,有了 Web Server 层的架构升级,比如 Structs、Spring MVC 等,这是后端的 MVC 时代。

3

代码可维护性得到明显好转,MVC 是个非常好的协作模式,从架构层面让开发者懂得什么代码应该写在什么地方。为了让 View 层更简单干脆,还可以选择 Velocity、Freemaker 等模板,使得模板里写不了 Java 代码。看起来是功能变弱了,但正是这种限制使得前后端分工更清晰。然而依旧并不是那么清晰,这个阶段的典型问题是:

1、**前端开发重度依赖开发环境。**这种架构下,前后端协作有两种模式:一种是前端写 demo,写好后,让后端去套模板。淘宝早期包括现在依旧有大量业务线是这种模式。好处很明显,demo 可以本地开发,很高效。不足是还需要后端套模板,有可能套错,套完后还需要前端确定,来回沟通调整的成本比较大。另一种协作模式是前端负责浏览器端的所有开发和服务器端的 View 层模板开发,支付宝是这种模式。好处是 UI 相关的代码都是前端去写就好,后端不用太关注,不足就是前端开发重度绑定后端环境,环境成为影响前端开发效率的重要因素。

2、**前后端职责依旧纠缠不清。**Velocity 模板还是蛮强大的,变量、逻辑、宏等特性,依旧可以通过拿到的上下文变量来实现各种业务逻辑。这样,只要前端弱势一点,往往就会被后端要求在模板层写出不少业务代码。还有一个很大的灰色地带是 Controller,页面路由等功能本应该是前端最关注的,但却是由后端来实现。Controller 本身与 Model 往往也会纠缠不清,看了让人咬牙的代码经常会出现在 Controller 层。这些问题不能全归结于程序员的素养,否则 JSP 就够了。

经常会有人吐槽 Java,但 Java 在工程化开发方面真的做了大量思考和架构尝试。Java 蛮符合马云的一句话:让平凡人做非凡事。

三、Ajax 带来的 SPA 时代

历史滚滚往前,2004 年 Gmail 像风一样的女子来到人间,很快 2005 年 Ajax 正式提出,加上 CDN 开始大量用于静态资源存储,于是出现了 JavaScript 王者归来的 SPA (Single Page Application 单页面应用)时代。

4

这种模式下,前后端的分工非常清晰,前后端的关键协作点是 Ajax 接口。看起来是如此美妙,但回过头来看看的话,这与 JSP 时代区别不大。复杂度从服务端的 JSP 里移到了浏览器的 JavaScript,浏览器端变得很复杂。类似 Spring MVC,这个时代开始出现浏览器端的分层架构:

5

对于 SPA 应用,有几个很重要的挑战:

1、**前后端接口的约定。**如果后端的接口一塌糊涂,如果后端的业务模型不够稳定,那么前端开发会很痛苦。这一块在业界有 API Blueprint 等方案来约定和沉淀接口,在阿里,不少团队也有类似尝试,通过接口规则、接口平台等方式来做。有了和后端一起沉淀的接口规则,还可以用来模拟数据,使得前后端可以在约定接口后实现高效并行开发。相信这一块会越做越好。

2、**前端开发的复杂度控制。**SPA 应用大多以功能交互型为主,JavaScript 代码过十万行很正常。大量 JS 代码的组织,与 View 层的绑定等,都不是容易的事情。典型的解决方案是业界的 Backbone,但 Backbone 做的事还很有限,依旧存在大量空白区域需要挑战。

SPA 让前端看到了一丝绿色,但依旧是在荒漠中行走。

四、前端为主的 MV* 时代

为了降低前端开发复杂度,除了 Backbone,还有大量框架涌现,比如 EmberJS、KnockoutJS、AngularJS 等等。这些框架总的原则是先按类型分层,比如 Templates、Controllers、Models,然后再在层内做切分,如下图:

6

好处很明显:

1、**前后端职责很清晰。**前端工作在浏览器端,后端工作在服务端。清晰的分工,可以让开发并行,测试数据的模拟不难,前端可以本地开发。后端则可以专注于业务逻辑的处理,输出 RESTful 等接口。

2、**前端开发的复杂度可控。**前端代码很重,但合理的分层,让前端代码能各司其职。这一块蛮有意思的,简单如模板特性的选择,就有很多很多讲究。并非越强大越好,限制什么,留下哪些自由,代码应该如何组织,所有这一切设计,得花一本的厚度去说明。

3、部署相对独立,产品体验可以快速改进。

但依旧有不足之处:

1、代码不能复用。比如后端依旧需要对数据做各种校验,校验逻辑无法复用浏览器端的代码。如果可以复用,那么后端的数据校验可以相对简单化。
2、全异步,对 SEO 不利。往往还需要服务端做同步渲染的降级方案。
3、性能并非最佳,特别是移动互联网环境下。
4、SPA 不能满足所有需求,依旧存在大量多页面应用。URL Design 需要后端配合,前端无法完全掌控。

五、Node 带来的全栈时代

前端为主的 MV* 模式解决了很多很多问题,但如上所述,依旧存在不少不足之处。随着 Node.js 的兴起,JavaScript 开始有能力运行在服务端。这意味着可以有一种新的研发模式:

7

在这种研发模式下,前后端的职责很清晰。对前端来说,两个 UI 层各司其职:

1、Front-end UI layer 处理浏览器层的展现逻辑。通过 CSS 渲染样式,通过 JavaScript 添加交互功能,HTML 的生成也可以放在这层,具体看应用场景。

2、Back-end UI layer 处理路由、模板、数据获取、cookie 等。通过路由,前端终于可以自主把控 URL Design,这样无论是单页面应用还是多页面应用,前端都可以自由调控。后端也终于可以摆脱对展现的强关注,转而可以专心于业务逻辑层的开发。

通过 Node,Web Server 层也是 JavaScript 代码,这意味着部分代码可前后复用,需要 SEO 的场景可以在服务端同步渲染,由于异步请求太多导致的性能问题也可以通过服务端来缓解。前一种模式的不足,通过这种模式几乎都能完美解决掉。

与 JSP 模式相比,全栈模式看起来是一种回归,也的确是一种向原始开发模式的回归,不过是一种螺旋上升式的回归。

基于 Node 的全栈模式,依旧面临很多挑战:

1、需要前端对服务端编程有更进一步的认识。比如 network/tcp、PE 等知识的掌握。
2、Node 层与 Java 层的高效通信。Node 模式下,都在服务器端,RESTful HTTP 通信未必高效,通过 SOAP 等方式通信更高效。一切需要在验证中前行。
3、对部署、运维层面的熟练了解,需要更多知识点和实操经验。
4、大量历史遗留问题如何过渡。这可能是最大最大的阻力。

六、小结

回顾历史总是让人感慨,展望未来则让人兴奋。上面讲到的研发模式,除了最后一种还在探索期,其他各种在各大公司都已有大量实践。几点小结:

1、模式没有好坏高下之分,只有合不合适。
2、Ajax 给前端开发带来了一次质的飞跃,Node 很可能是第二次。
3、SoC(关注度分离) 是一条伟大的原则。上面种种模式,都是让前后端的职责更清晰,分工更合理高效。
4、还有个原则,让合适的人做合适的事。比如 Web Server 层的 UI Layer 开发,前端是更合适的人选。

历史有时候会打转,咋一看以为是回去了,实际上是螺旋转了一圈,站在了一个新的起点。

(完)

题图:演化真不容易呀。


欢迎订阅 WTP(Web 技术与产品交流)微信公众帐号。WTP 关注技术、产品、自由梦,只推送原创文字。欢迎扫描二维码订阅:

@viccici

This comment has been minimized.

Show comment
Hide comment
@viccici

viccici Jan 13, 2014

合适的时间与合适的技术。

viccici commented Jan 13, 2014

合适的时间与合适的技术。

@alvinhui

This comment has been minimized.

Show comment
Hide comment
@alvinhui

alvinhui Jan 13, 2014

最后一个全栈时代,我厂也有一些实践。社会分工粒度越来越细了,对于提高生产力确实有很大的促进作用,互联网企业很快迎来“工厂时代”。但是站在个人的角度去看,又觉得有点儿沮丧……

两个别扭的:

第四点不属于“Web 研发模式演变”这个主题吧。。。

“2、Ajax 给前端开发带来了一次质的飞跃,Node 很可能是第二次。” 对于Node的论述不同意。

================我是分割线小朋友===================

可惜看玉伯文章的大多数都是前端程序员。要是架构师、后端们也来关注一下前端的圈子,很多事情才能更快地推动起来。

alvinhui commented Jan 13, 2014

最后一个全栈时代,我厂也有一些实践。社会分工粒度越来越细了,对于提高生产力确实有很大的促进作用,互联网企业很快迎来“工厂时代”。但是站在个人的角度去看,又觉得有点儿沮丧……

两个别扭的:

第四点不属于“Web 研发模式演变”这个主题吧。。。

“2、Ajax 给前端开发带来了一次质的飞跃,Node 很可能是第二次。” 对于Node的论述不同意。

================我是分割线小朋友===================

可惜看玉伯文章的大多数都是前端程序员。要是架构师、后端们也来关注一下前端的圈子,很多事情才能更快地推动起来。

@guilipan

This comment has been minimized.

Show comment
Hide comment
@guilipan

guilipan Jan 13, 2014

nodejs在处理复杂的业务逻辑确实不适合,但是处理显示逻辑简直是神器

guilipan commented Jan 13, 2014

nodejs在处理复杂的业务逻辑确实不适合,但是处理显示逻辑简直是神器

@YSlove

This comment has been minimized.

Show comment
Hide comment
@YSlove

YSlove Jan 13, 2014

怎么说呢,只有适合跟不适合,善用与不善用。应用为王,其他都是支持为主。没有对错,只有支持的速度与质量差异。任何程序说白了都是利益链条,无利不起早。

YSlove commented Jan 13, 2014

怎么说呢,只有适合跟不适合,善用与不善用。应用为王,其他都是支持为主。没有对错,只有支持的速度与质量差异。任何程序说白了都是利益链条,无利不起早。

@huangyingjie

This comment has been minimized.

Show comment
Hide comment
@huangyingjie

huangyingjie Jan 13, 2014

前端操控路由这块,如果前端也掌握java或者php,这不是问题,问题是,前端有没有涉足这块的权力;前后端都用js,未必就能提高可维护性。前后端共用同一代码,这个不错。

huangyingjie commented Jan 13, 2014

前端操控路由这块,如果前端也掌握java或者php,这不是问题,问题是,前端有没有涉足这块的权力;前后端都用js,未必就能提高可维护性。前后端共用同一代码,这个不错。

@dqw

This comment has been minimized.

Show comment
Hide comment
@dqw

dqw Jan 14, 2014

前端后端的最大区别其实是知识体系不同,和用什么语言关系不大
后端学习javascript困难不大,其实很快就能上手,相对前端学习整个后端的知识体系会困难很多吧
彼此学习一些对方的东西沟通效率会高很多
我是后端,最烦套模板了,前后端两遍验证确实很麻烦,有时候修改还造成不一致

dqw commented Jan 14, 2014

前端后端的最大区别其实是知识体系不同,和用什么语言关系不大
后端学习javascript困难不大,其实很快就能上手,相对前端学习整个后端的知识体系会困难很多吧
彼此学习一些对方的东西沟通效率会高很多
我是后端,最烦套模板了,前后端两遍验证确实很麻烦,有时候修改还造成不一致

@xiongsongsong

This comment has been minimized.

Show comment
Hide comment
@xiongsongsong

xiongsongsong Jan 14, 2014

@alvinhui Node的确很可能是第二次。

其一:Ajax很不爽的一点是,比同步慢。要客户端发起至少第2次请求后,才能得到结果。如果用Node,可以直接在服务器将数据组装好返回。这一点咋看起来没什么意思,但想象的空间很大,意味着前端可以自主实现一些业务,开发专注于接口的实现。

其二:有必要提下JSON,JSON数据表达能力超强,而不像干瘪瘪的二维表。开发说,写SQL的时候,把数据想象成一个平面。这是没办法的事情,因为二维表就是行和列,数据表现离不了主键外键。JSON就不一样了,它是作为数据交换和表达的极为理想的格式,至少目前我这么觉得。如果条件允许,如果当前存在MongoDB的DBA,那么前端的研发模式的确要转变了。

xiongsongsong commented Jan 14, 2014

@alvinhui Node的确很可能是第二次。

其一:Ajax很不爽的一点是,比同步慢。要客户端发起至少第2次请求后,才能得到结果。如果用Node,可以直接在服务器将数据组装好返回。这一点咋看起来没什么意思,但想象的空间很大,意味着前端可以自主实现一些业务,开发专注于接口的实现。

其二:有必要提下JSON,JSON数据表达能力超强,而不像干瘪瘪的二维表。开发说,写SQL的时候,把数据想象成一个平面。这是没办法的事情,因为二维表就是行和列,数据表现离不了主键外键。JSON就不一样了,它是作为数据交换和表达的极为理想的格式,至少目前我这么觉得。如果条件允许,如果当前存在MongoDB的DBA,那么前端的研发模式的确要转变了。

@qqqzhch

This comment has been minimized.

Show comment
Hide comment
@qqqzhch

qqqzhch Jan 14, 2014

好文 收藏了

qqqzhch commented Jan 14, 2014

好文 收藏了

@xiongsongsong

This comment has been minimized.

Show comment
Hide comment
@xiongsongsong

xiongsongsong Jan 14, 2014

@dqw 前端的知识体系里面,JS只是其中一部分呢。

xiongsongsong commented Jan 14, 2014

@dqw 前端的知识体系里面,JS只是其中一部分呢。

@xufei

This comment has been minimized.

Show comment
Hide comment
@xufei

xufei Jan 14, 2014

最后这个图是月影翻译的那篇文章中的,我也一直在思考最后一步,可能会搬一套类似npm的东西到上面去,但是开发阶段跟运行阶段的分界在哪里,还在纠结。

xufei commented Jan 14, 2014

最后这个图是月影翻译的那篇文章中的,我也一直在思考最后一步,可能会搬一套类似npm的东西到上面去,但是开发阶段跟运行阶段的分界在哪里,还在纠结。

@qqqzhch

This comment has been minimized.

Show comment
Hide comment
@qqqzhch

qqqzhch Jan 14, 2014

看完了 不错

qqqzhch commented Jan 14, 2014

看完了 不错

@houfeng0923

This comment has been minimized.

Show comment
Hide comment
@houfeng0923

houfeng0923 Jan 14, 2014

前段时间也对web应用开发模式做了一些回顾和总结,分类也大致相当,但远没玉伯老师总结的清晰、条理。学习了。

第五点(Node带来的全栈时代)确实是个让人兴奋的模式,去年yahoo开源了基于yui3的 mojito 应该算是这种模式的尝试。只不过它更彻底,后端完全基于Node.js 。

houfeng0923 commented Jan 14, 2014

前段时间也对web应用开发模式做了一些回顾和总结,分类也大致相当,但远没玉伯老师总结的清晰、条理。学习了。

第五点(Node带来的全栈时代)确实是个让人兴奋的模式,去年yahoo开源了基于yui3的 mojito 应该算是这种模式的尝试。只不过它更彻底,后端完全基于Node.js 。

@hanzheng

This comment has been minimized.

Show comment
Hide comment
@hanzheng

hanzheng Jan 14, 2014

我厂走到四了,五还不想尝试。。。

hanzheng commented Jan 14, 2014

我厂走到四了,五还不想尝试。。。

@elover

This comment has been minimized.

Show comment
Hide comment
@elover

elover Jan 14, 2014

本来想走到4但是因为兼容性,认证等问题,现在想试试5,但是目前这种解决方案还太少,到时候做的时候可能也会有不少的坑吧?而且,性能上有可能会比较慢一下,最后前端要介入以前属于后端的一些东西阻力还是比较大的。

elover commented Jan 14, 2014

本来想走到4但是因为兼容性,认证等问题,现在想试试5,但是目前这种解决方案还太少,到时候做的时候可能也会有不少的坑吧?而且,性能上有可能会比较慢一下,最后前端要介入以前属于后端的一些东西阻力还是比较大的。

@shiran565

This comment has been minimized.

Show comment
Hide comment
@shiran565

shiran565 Jan 14, 2014

对于5的确非常感兴趣,但是很难去说服管理层去做出决策去改变,决策者一般不会愿意仅仅为改变开发模式而付出太大代价,除非它能带来效率上的极大提升

shiran565 commented Jan 14, 2014

对于5的确非常感兴趣,但是很难去说服管理层去做出决策去改变,决策者一般不会愿意仅仅为改变开发模式而付出太大代价,除非它能带来效率上的极大提升

@lifesinger

This comment has been minimized.

Show comment
Hide comment
@lifesinger

lifesinger Jan 14, 2014

Owner

支付宝已经在尝试了,打动管理层有两点:1)性能提升、成本降低,如果能证明通过 Node
可以降低服务器数量,那么成本的节省会比较可观。2)研发效率的提升,前后端都更快速,如果能拿到数据比对,也会非常不错。

2014/1/14 shrian notifications@github.com

对于5的确非常感兴趣,但是很难去说服管理层去做出决策去改变,决策者一般不会愿意仅仅为改变开发模式而付出太大代价,除非它能带来效率上的极大提升


Reply to this email directly or view it on GitHubhttps://github.com//issues/184#issuecomment-32242724
.

王保平 / 玉伯(射雕)
送人玫瑰手有余香

Owner

lifesinger commented Jan 14, 2014

支付宝已经在尝试了,打动管理层有两点:1)性能提升、成本降低,如果能证明通过 Node
可以降低服务器数量,那么成本的节省会比较可观。2)研发效率的提升,前后端都更快速,如果能拿到数据比对,也会非常不错。

2014/1/14 shrian notifications@github.com

对于5的确非常感兴趣,但是很难去说服管理层去做出决策去改变,决策者一般不会愿意仅仅为改变开发模式而付出太大代价,除非它能带来效率上的极大提升


Reply to this email directly or view it on GitHubhttps://github.com//issues/184#issuecomment-32242724
.

王保平 / 玉伯(射雕)
送人玫瑰手有余香

@Wuvist

This comment has been minimized.

Show comment
Hide comment
@Wuvist

Wuvist Jan 14, 2014

印象中paypal也走了全栈这条路:http://www.infoq.com/news/2013/11/paypal-java-javascript

做为后端开发者,我对node本身其实很不看好,纯粹考虑后端的话,我会认为后端可以其它有比node更好的选择。就性能提升、成本降低这点而言,node可以做到的,还会有别的方案也可以做到,甚至更好做好。

前后端的代码复用,大头应该是模板,而这层应该可以通过使用mustache之类语言无关的模板引擎达到同样效果。

我会更加期待看到一些后端非node,并且跟前端共享模板的方案;个人两年前也用py在 http://meishiwanjia.com 做过尝试,后端的tornado跟前端的jquery(当然,还用了seajs~)使用同样的模板: http://www.slideshare.net/Wuvist/tornado-9296213 slide 29+

当然,综合而言,肯定还是js + node这样同一语言能够达到的开发效率会更高。但如果前后端都是同一开发者负责开发,从管理的角度看,我猜未必会更好:全栈开发者本身可能会成为瓶颈。

Wuvist commented Jan 14, 2014

印象中paypal也走了全栈这条路:http://www.infoq.com/news/2013/11/paypal-java-javascript

做为后端开发者,我对node本身其实很不看好,纯粹考虑后端的话,我会认为后端可以其它有比node更好的选择。就性能提升、成本降低这点而言,node可以做到的,还会有别的方案也可以做到,甚至更好做好。

前后端的代码复用,大头应该是模板,而这层应该可以通过使用mustache之类语言无关的模板引擎达到同样效果。

我会更加期待看到一些后端非node,并且跟前端共享模板的方案;个人两年前也用py在 http://meishiwanjia.com 做过尝试,后端的tornado跟前端的jquery(当然,还用了seajs~)使用同样的模板: http://www.slideshare.net/Wuvist/tornado-9296213 slide 29+

当然,综合而言,肯定还是js + node这样同一语言能够达到的开发效率会更高。但如果前后端都是同一开发者负责开发,从管理的角度看,我猜未必会更好:全栈开发者本身可能会成为瓶颈。

@zzxadi

This comment has been minimized.

Show comment
Hide comment
@zzxadi

zzxadi Jan 14, 2014

任何技术的发展都有一个类似的过程,想起来《Unix 编程艺术》中开篇的一句话,不懂Unix的人最终还会发明一个蹩脚的Unix。

zzxadi commented Jan 14, 2014

任何技术的发展都有一个类似的过程,想起来《Unix 编程艺术》中开篇的一句话,不懂Unix的人最终还会发明一个蹩脚的Unix。

@lifesinger

This comment has been minimized.

Show comment
Hide comment
@lifesinger

lifesinger Jan 14, 2014

Owner

@Wuvist mustache 等方式能共享的是模板片段,不能从页面整体来优化模板,难以享受 block、filters 等特性。整体化的模板替换方案,对文件组织带来的好处更多,对效率的提升更大。mustache 等方案有点为了共享而共享,牺牲太多。

之所以我觉得是 node,是因为 javascript,因为熟悉,加上适度侵入服务端(不是把服务端的活都干了,而是只负责后端 view、router 等前端相关的活),这种全栈非常谨慎,依旧需要后端的全力配合,核心是让合适人干合适的事,是分工的重新思考和细节调整,因此我觉得是人员上是可控的,可以尝试的。

Owner

lifesinger commented Jan 14, 2014

@Wuvist mustache 等方式能共享的是模板片段,不能从页面整体来优化模板,难以享受 block、filters 等特性。整体化的模板替换方案,对文件组织带来的好处更多,对效率的提升更大。mustache 等方案有点为了共享而共享,牺牲太多。

之所以我觉得是 node,是因为 javascript,因为熟悉,加上适度侵入服务端(不是把服务端的活都干了,而是只负责后端 view、router 等前端相关的活),这种全栈非常谨慎,依旧需要后端的全力配合,核心是让合适人干合适的事,是分工的重新思考和细节调整,因此我觉得是人员上是可控的,可以尝试的。

@Wuvist

This comment has been minimized.

Show comment
Hide comment
@Wuvist

Wuvist Jan 14, 2014

@lifesinger 重新把你原文看了几遍;应该终于理解你意思了哈哈不过,我反过来却又会怀疑“性能提升、成本降低,如果能证明通过 Node可以降低服务器数量”这目标。

原来的后端直接渲染jsp模板,性能应该要比由后端输出数据,然后node再渲染模板要好。不管node本身性能如何,它在这里是新的一层overhead。

Wuvist commented Jan 14, 2014

@lifesinger 重新把你原文看了几遍;应该终于理解你意思了哈哈不过,我反过来却又会怀疑“性能提升、成本降低,如果能证明通过 Node可以降低服务器数量”这目标。

原来的后端直接渲染jsp模板,性能应该要比由后端输出数据,然后node再渲染模板要好。不管node本身性能如何,它在这里是新的一层overhead。

@chemzqm

This comment has been minimized.

Show comment
Hide comment
@chemzqm

chemzqm Jan 14, 2014

使用node共享的不仅是模板,我们项目里面有许多模块都是复用的,比如http请求使用superagent,日期处理使用momentjs,异步处理使用serial和parallel(一开始使用的promise也是完全一样的代码),另外还有JSON解析的一致性也是其它语言做不到的。

chemzqm commented Jan 14, 2014

使用node共享的不仅是模板,我们项目里面有许多模块都是复用的,比如http请求使用superagent,日期处理使用momentjs,异步处理使用serial和parallel(一开始使用的promise也是完全一样的代码),另外还有JSON解析的一致性也是其它语言做不到的。

@xufei

This comment has been minimized.

Show comment
Hide comment
@xufei

xufei Jan 15, 2014

@Wuvist 性能未必好,重点是把可能占应用服务器资源的一些非关键代码抽到外面来,比如模板、国际化这些东西,应用服务器应专注于处理真正的业务,其性能不应被这些外部的东西干扰

xufei commented Jan 15, 2014

@Wuvist 性能未必好,重点是把可能占应用服务器资源的一些非关键代码抽到外面来,比如模板、国际化这些东西,应用服务器应专注于处理真正的业务,其性能不应被这些外部的东西干扰

@Wuvist

This comment has been minimized.

Show comment
Hide comment
@Wuvist

Wuvist Jan 15, 2014

@xufei 但按 @lifesinger 的说法,“性能提升、成本降低,如果能证明通过 Node
可以降低服务器数量,那么成本的节省会比较可观”是“打动管理层”支持尝试加入node做全栈的两点理由之一。

不过换个角度看,很多公司(比方我现在的公司)应该也是ajax前端一层,然后php UI一层,然后再是后端各种service。其中ajax前端由前端团队负责;php + 各种service由后端团队负责。那么,玉伯说的5,相对于这样的架构,是把php换成了node,并且负责的团队由后端变成前端。

node相对于php,也许可以获得性能提升;并且还有各种代码共享的好处。但相应的问题是如 @chemzqm 所说的node人员不好招。

我一直都对node不感冒,因为我实在不觉得它是一个后端开发的好选择;但看到这篇文后,对于 @lifesinger 提出的这种把node做为UI渲染的“后端服务器"的使用方式,我觉得还是很有道理,很值得尝试的。

以后端开发而言,我会更加看好go,但目前go在UI渲染方面还是比较弱,把go挪去“真·后端”,UI渲染换成node,我觉得会是挺不错的选择。

Wuvist commented Jan 15, 2014

@xufei 但按 @lifesinger 的说法,“性能提升、成本降低,如果能证明通过 Node
可以降低服务器数量,那么成本的节省会比较可观”是“打动管理层”支持尝试加入node做全栈的两点理由之一。

不过换个角度看,很多公司(比方我现在的公司)应该也是ajax前端一层,然后php UI一层,然后再是后端各种service。其中ajax前端由前端团队负责;php + 各种service由后端团队负责。那么,玉伯说的5,相对于这样的架构,是把php换成了node,并且负责的团队由后端变成前端。

node相对于php,也许可以获得性能提升;并且还有各种代码共享的好处。但相应的问题是如 @chemzqm 所说的node人员不好招。

我一直都对node不感冒,因为我实在不觉得它是一个后端开发的好选择;但看到这篇文后,对于 @lifesinger 提出的这种把node做为UI渲染的“后端服务器"的使用方式,我觉得还是很有道理,很值得尝试的。

以后端开发而言,我会更加看好go,但目前go在UI渲染方面还是比较弱,把go挪去“真·后端”,UI渲染换成node,我觉得会是挺不错的选择。

@lifesinger

This comment has been minimized.

Show comment
Hide comment
@lifesinger

lifesinger Jan 15, 2014

Owner

@Wuvist 可以无视我的理由,之所以提那两点,是因为这两点是短期内有可能看得见的。引入 node 的全栈模式,更多受益在长期,比如

  1. 前端的研发效率,这个长期才能看得出来,起步阶段需要的是相信。
  2. 逼着前后端协作往接口化靠,甚至把接口都 RESTful 化。这个光口头叫叫是做不出来的,得研发模式中有破局之处。

招聘的问题,直接招很难,内部培养还是相对容易的。需要的是团队里有1-2个专家级人物,然后逐步培养,逐步吸引。

Owner

lifesinger commented Jan 15, 2014

@Wuvist 可以无视我的理由,之所以提那两点,是因为这两点是短期内有可能看得见的。引入 node 的全栈模式,更多受益在长期,比如

  1. 前端的研发效率,这个长期才能看得出来,起步阶段需要的是相信。
  2. 逼着前后端协作往接口化靠,甚至把接口都 RESTful 化。这个光口头叫叫是做不出来的,得研发模式中有破局之处。

招聘的问题,直接招很难,内部培养还是相对容易的。需要的是团队里有1-2个专家级人物,然后逐步培养,逐步吸引。

@Wuvist

This comment has been minimized.

Show comment
Hide comment
@Wuvist

Wuvist Jan 15, 2014

@lifesinger "逼着前后端协作往接口化靠,甚至把接口都 RESTful 化。这个光口头叫叫是做不出来的,得研发模式中有破局之处。"咦?我以为阿里/淘宝/支付宝早就SOA了?

Wuvist commented Jan 15, 2014

@lifesinger "逼着前后端协作往接口化靠,甚至把接口都 RESTful 化。这个光口头叫叫是做不出来的,得研发模式中有破局之处。"咦?我以为阿里/淘宝/支付宝早就SOA了?

@lifesinger

This comment has been minimized.

Show comment
Hide comment
@lifesinger

lifesinger Jan 15, 2014

Owner

UI 层没接口化,还是 Velocity 变量搅拌成一团

2014/1/15 Wuvist notifications@github.com

@lifesinger https://github.com/lifesinger "逼着前后端协作往接口化靠,甚至把接口都 RESTful
化。这个光口头叫叫是做不出来的,得研发模式中有破局之处。"咦?我以为阿里/淘宝早就SOA了?


Reply to this email directly or view it on GitHubhttps://github.com//issues/184#issuecomment-32330628
.

王保平 / 玉伯(射雕)
送人玫瑰手有余香

Owner

lifesinger commented Jan 15, 2014

UI 层没接口化,还是 Velocity 变量搅拌成一团

2014/1/15 Wuvist notifications@github.com

@lifesinger https://github.com/lifesinger "逼着前后端协作往接口化靠,甚至把接口都 RESTful
化。这个光口头叫叫是做不出来的,得研发模式中有破局之处。"咦?我以为阿里/淘宝早就SOA了?


Reply to this email directly or view it on GitHubhttps://github.com//issues/184#issuecomment-32330628
.

王保平 / 玉伯(射雕)
送人玫瑰手有余香

@chemzqm

This comment has been minimized.

Show comment
Hide comment
@chemzqm

chemzqm Jan 15, 2014

从付出、收益来讲小公司根本培养不起,因为受众太少,而且还容易跑路,让专业的人付出太多精力去做培训得不偿失。往全端走障碍还是蛮多的,首先是前端上光会jquery underscore那些工具肯定远远不够,然后是前后端API设计上的得失考量,学会node里面那些常用模块和API我个人觉得是最容易的,建议基础不是太好的同学先把语言和协议的基础打好一些,不要想着一步跨入全端。

On 2014年1月15日, at 10:50, lifesinger notifications@github.com wrote:

@Wuvist 可以无视我的理由,之所以提那两点,是因为这两点是短期内有可能看得见的。引入 node 的全栈模式,更多受益在长期,比如

前端的研发效率,这个长期才能看得出来,起步阶段需要的是相信。
逼着前后端协作往接口化靠,甚至把接口都 RESTful 化。这个光口头叫叫是做不出来的,得研发模式中有破局之处。
招聘的问题,直接招很难,内部培养还是相对容易的。需要的是团队里有1-2个专家级人物,然后逐步培养,逐步吸引。


Reply to this email directly or view it on GitHub.

chemzqm commented Jan 15, 2014

从付出、收益来讲小公司根本培养不起,因为受众太少,而且还容易跑路,让专业的人付出太多精力去做培训得不偿失。往全端走障碍还是蛮多的,首先是前端上光会jquery underscore那些工具肯定远远不够,然后是前后端API设计上的得失考量,学会node里面那些常用模块和API我个人觉得是最容易的,建议基础不是太好的同学先把语言和协议的基础打好一些,不要想着一步跨入全端。

On 2014年1月15日, at 10:50, lifesinger notifications@github.com wrote:

@Wuvist 可以无视我的理由,之所以提那两点,是因为这两点是短期内有可能看得见的。引入 node 的全栈模式,更多受益在长期,比如

前端的研发效率,这个长期才能看得出来,起步阶段需要的是相信。
逼着前后端协作往接口化靠,甚至把接口都 RESTful 化。这个光口头叫叫是做不出来的,得研发模式中有破局之处。
招聘的问题,直接招很难,内部培养还是相对容易的。需要的是团队里有1-2个专家级人物,然后逐步培养,逐步吸引。


Reply to this email directly or view it on GitHub.

@xingrz

This comment has been minimized.

Show comment
Hide comment
@xingrz

xingrz Jan 15, 2014

(虽然之前在微博提问过,但感觉这里问的话讨论氛围好一些。)

我们团队也是采用第五种开发模式,后端使用 Golang。

总体上大家都用得很愉快,但是我有一个地方比较纠结:用户会话应该由后端还是 Node 来维护?

如果由后端维护

后端生成会话 token 丢给 Node;Node 将 token 存入 Cookie,每次请求时发送给后端作为用户身份鉴别,以此来获取用户 id。

此时 Node 的职责仅仅是�渲染模板、处理路由,纯粹是浏览器也业务后端之间的一个中转器。

如果由 Node 维护

由 Node 生成会话 token(此时的 token 就是大家理解的 Session 存到 Cookie 里的 Session ID 了),由 Node 维护用户 id 等会话数据(可能使用 redis 做持久化);Node 与后端的通讯直接使用用户 id 来区分用户,也就是说后端无条件信任 Node 带过来的用户 id。

此时对于 Node 来说,可以把后端看做一个「数据库」。后端只保证进出的数据在业务上的正确性,而不处理会话。


不知道各位对这两种方式有什么看法?

xingrz commented Jan 15, 2014

(虽然之前在微博提问过,但感觉这里问的话讨论氛围好一些。)

我们团队也是采用第五种开发模式,后端使用 Golang。

总体上大家都用得很愉快,但是我有一个地方比较纠结:用户会话应该由后端还是 Node 来维护?

如果由后端维护

后端生成会话 token 丢给 Node;Node 将 token 存入 Cookie,每次请求时发送给后端作为用户身份鉴别,以此来获取用户 id。

此时 Node 的职责仅仅是�渲染模板、处理路由,纯粹是浏览器也业务后端之间的一个中转器。

如果由 Node 维护

由 Node 生成会话 token(此时的 token 就是大家理解的 Session 存到 Cookie 里的 Session ID 了),由 Node 维护用户 id 等会话数据(可能使用 redis 做持久化);Node 与后端的通讯直接使用用户 id 来区分用户,也就是说后端无条件信任 Node 带过来的用户 id。

此时对于 Node 来说,可以把后端看做一个「数据库」。后端只保证进出的数据在业务上的正确性,而不处理会话。


不知道各位对这两种方式有什么看法?

@lifesinger

This comment has been minimized.

Show comment
Hide comment
@lifesinger

lifesinger Jan 16, 2014

Owner

@xingrz 支付宝目前想尝试第一种方式:session 由后端维护,Node 通过 node-tair 模块去读取 session 信息。这样做是基于支付宝目前的技术体系,后端 session 层已经很复杂,比如分布式 session 等,这些逻辑如果用 Node 重新实现,代价很大。

如果是轻量级应用,session 由 Node 来维护可能也是不错的选择,这个我们没尝试,就不评价了。

Owner

lifesinger commented Jan 16, 2014

@xingrz 支付宝目前想尝试第一种方式:session 由后端维护,Node 通过 node-tair 模块去读取 session 信息。这样做是基于支付宝目前的技术体系,后端 session 层已经很复杂,比如分布式 session 等,这些逻辑如果用 Node 重新实现,代价很大。

如果是轻量级应用,session 由 Node 来维护可能也是不错的选择,这个我们没尝试,就不评价了。

@xingrz

This comment has been minimized.

Show comment
Hide comment
@xingrz

xingrz Jan 16, 2014

谢谢玉伯老师的回复。

实际上我们团队现在用到这种结构的两个产品都是由后端维护 session。

当时原本的结构是后端完全用 go 实现,后来发现 go 渲染 html 实在痛苦,才加了一层 node;而且当时还打算手机客户端直接与 go
后端打交道,所以就把用户会话做在 go 了。

直到后来再仔细思考这种结构的时候才想到了由 node 维护 session 的方式,因为这样对于「明显不合法」的请求,比如无效 session
id,可以直接在 node 层拒掉,少走两段路程。而且后端也不应该暴露给外网,诸如手机客户端用的接口需要再包一层认证和会话维护。

另外当时对这种方式的想法还有,后端与 node 可以使用诸如 protobuf 之类更高效的序列化协议,协议带上版本等。不过这些还停留在设想。


在地铁上码字,可能有点不通顺。
2014年1月16日 上午9:23于 "lifesinger" notifications@github.com写道:

@xingrz https://github.com/xingrz 支付宝目前想尝试第一种方式:session 由后端维护,Node 通过
node-tair 模块去读取 session 信息。这样做是基于支付宝目前的技术体系,后端 session 层已经很复杂,比如分布式 session
等,这些逻辑如果用 Node 重新实现,代价很大。

如果是轻量级应用,session 由 Node 来维护可能也是不错的选择,这个我们没尝试,就不评价了。


Reply to this email directly or view it on
GitHubhttps://github.com//issues/184#issuecomment-32434110
.

xingrz commented Jan 16, 2014

谢谢玉伯老师的回复。

实际上我们团队现在用到这种结构的两个产品都是由后端维护 session。

当时原本的结构是后端完全用 go 实现,后来发现 go 渲染 html 实在痛苦,才加了一层 node;而且当时还打算手机客户端直接与 go
后端打交道,所以就把用户会话做在 go 了。

直到后来再仔细思考这种结构的时候才想到了由 node 维护 session 的方式,因为这样对于「明显不合法」的请求,比如无效 session
id,可以直接在 node 层拒掉,少走两段路程。而且后端也不应该暴露给外网,诸如手机客户端用的接口需要再包一层认证和会话维护。

另外当时对这种方式的想法还有,后端与 node 可以使用诸如 protobuf 之类更高效的序列化协议,协议带上版本等。不过这些还停留在设想。


在地铁上码字,可能有点不通顺。
2014年1月16日 上午9:23于 "lifesinger" notifications@github.com写道:

@xingrz https://github.com/xingrz 支付宝目前想尝试第一种方式:session 由后端维护,Node 通过
node-tair 模块去读取 session 信息。这样做是基于支付宝目前的技术体系,后端 session 层已经很复杂,比如分布式 session
等,这些逻辑如果用 Node 重新实现,代价很大。

如果是轻量级应用,session 由 Node 来维护可能也是不错的选择,这个我们没尝试,就不评价了。


Reply to this email directly or view it on
GitHubhttps://github.com//issues/184#issuecomment-32434110
.

@zproo

This comment has been minimized.

Show comment
Hide comment
@zproo

zproo Jun 3, 2017

看似简单的道理却很少有人能讲的如此清晰。先给徐大佬点赞!
但是加入Node做服务端渲染势必增加了开发复杂度,还有对性能的影响?对稳定性的影响?
阿里已经尝试几年了,现在的迁移过程是什么进度?迁移后效果如何?这个架构是否值得广泛使用?
希望博主以后有时间可以更新一集!关注!!

zproo commented Jun 3, 2017

看似简单的道理却很少有人能讲的如此清晰。先给徐大佬点赞!
但是加入Node做服务端渲染势必增加了开发复杂度,还有对性能的影响?对稳定性的影响?
阿里已经尝试几年了,现在的迁移过程是什么进度?迁移后效果如何?这个架构是否值得广泛使用?
希望博主以后有时间可以更新一集!关注!!

@calidion

This comment has been minimized.

Show comment
Hide comment
@calidion

calidion Jun 3, 2017

@zproo

这里认为Node是前端,你问Node服务器端渲染。果然是高人。哈哈。

另:

如果阿里的技术人员有足够的判断,这种错误思想肯定一开始就被灭了。

所以不存在迁移的问题。

并且结果也只有两种可能,一种是后端转向Node,另一种是后端继续使用其它语言。

并不会发生大前端和这里所谓的”前后端分离“这样的事情。

时间确实是最好的证明。 哈哈。

calidion commented Jun 3, 2017

@zproo

这里认为Node是前端,你问Node服务器端渲染。果然是高人。哈哈。

另:

如果阿里的技术人员有足够的判断,这种错误思想肯定一开始就被灭了。

所以不存在迁移的问题。

并且结果也只有两种可能,一种是后端转向Node,另一种是后端继续使用其它语言。

并不会发生大前端和这里所谓的”前后端分离“这样的事情。

时间确实是最好的证明。 哈哈。

@yiakwy

This comment has been minimized.

Show comment
Hide comment
@yiakwy

yiakwy Jun 3, 2017

yiakwy commented Jun 3, 2017

@yiakwy

This comment has been minimized.

Show comment
Hide comment
@yiakwy

yiakwy Jun 3, 2017

yiakwy commented Jun 3, 2017

@yiakwy

This comment has been minimized.

Show comment
Hide comment
@yiakwy

yiakwy Jun 3, 2017

yiakwy commented Jun 3, 2017

@yiakwy

This comment has been minimized.

Show comment
Hide comment
@yiakwy

yiakwy Jun 3, 2017

yiakwy commented Jun 3, 2017

@calidion

This comment has been minimized.

Show comment
Hide comment
@calidion

calidion Jun 6, 2017

@atian25

有意思啊。

还偷偷的点 👎

你有道理可拿出来说说?

本来不太想说你,毕竟你说我眼界低,我也承认。

何况我还做了好几个打你们这群人脸的项目。

但是你为了证明你的眼界高偷了我的框架名(egg),然后还写的性能比我的框架低很多,理念上还是抱着基本的MVC这样落后的观念。写出来了比垃圾回收站还牛的eggjs,什么都往上堆,就差将整个npm包装进eggjs了。

这就是你所谓的有眼界吧?眼界高就是去做低水平重复建设的事情?

看来我的世界观也得改一下了。

据我了解的眼界高的项目比如seajs,再比如eggjs:)

估计你们这些人都是眼界高一派的老手。

当然你们眼界高肯定跟你们公司是无关的,是真高,放在那里都是一座高山。

因为我的框架处理每个请求的时间比eggjs低3倍多,所以我的眼界确实不行。

希望eggjs可以向眼界高处走,将处理时间再提高点。哈哈。

对了差点忘记了,为了证明你们眼界高,你们一定不要忘记将所有你们知道的设计模式引入到eggjs中去。

否则就会跟我的vig框架一样,没有任何可以证明自己眼界高的名词了。

会很丢人的,会被认为眼界低:)

不过eggjs终于让我理解了眼界高是什么意思:就是低水平重复建设:)

calidion commented Jun 6, 2017

@atian25

有意思啊。

还偷偷的点 👎

你有道理可拿出来说说?

本来不太想说你,毕竟你说我眼界低,我也承认。

何况我还做了好几个打你们这群人脸的项目。

但是你为了证明你的眼界高偷了我的框架名(egg),然后还写的性能比我的框架低很多,理念上还是抱着基本的MVC这样落后的观念。写出来了比垃圾回收站还牛的eggjs,什么都往上堆,就差将整个npm包装进eggjs了。

这就是你所谓的有眼界吧?眼界高就是去做低水平重复建设的事情?

看来我的世界观也得改一下了。

据我了解的眼界高的项目比如seajs,再比如eggjs:)

估计你们这些人都是眼界高一派的老手。

当然你们眼界高肯定跟你们公司是无关的,是真高,放在那里都是一座高山。

因为我的框架处理每个请求的时间比eggjs低3倍多,所以我的眼界确实不行。

希望eggjs可以向眼界高处走,将处理时间再提高点。哈哈。

对了差点忘记了,为了证明你们眼界高,你们一定不要忘记将所有你们知道的设计模式引入到eggjs中去。

否则就会跟我的vig框架一样,没有任何可以证明自己眼界高的名词了。

会很丢人的,会被认为眼界低:)

不过eggjs终于让我理解了眼界高是什么意思:就是低水平重复建设:)

@zhangzhenhua92

This comment has been minimized.

Show comment
Hide comment
@zhangzhenhua92

zhangzhenhua92 Jul 8, 2017

纯粹来涨涨知识,简直太棒了。

zhangzhenhua92 commented Jul 8, 2017

纯粹来涨涨知识,简直太棒了。

@Jandaes

This comment has been minimized.

Show comment
Hide comment
@Jandaes

Jandaes Jul 10, 2017

看了对web分工合作更加详细了解了、但是这样的话、java后台是不是只要提供webservice的RESTful 就行了!那什么重定向、转发的都不用吗?

Jandaes commented Jul 10, 2017

看了对web分工合作更加详细了解了、但是这样的话、java后台是不是只要提供webservice的RESTful 就行了!那什么重定向、转发的都不用吗?

@calidion

This comment has been minimized.

Show comment
Hide comment
@calidion

calidion Jul 10, 2017

@Jandaes

少看阿里一些技术人员的奇谈怪论,特别是阿里早期技术员工的言论。

如果你知道了阿里某些表演系技术人员连中间件是什么都搞不清楚的话。

你就应该对此不会奇怪。

https://t1bao.com/thread/visit/57

calidion commented Jul 10, 2017

@Jandaes

少看阿里一些技术人员的奇谈怪论,特别是阿里早期技术员工的言论。

如果你知道了阿里某些表演系技术人员连中间件是什么都搞不清楚的话。

你就应该对此不会奇怪。

https://t1bao.com/thread/visit/57

@jedyang

This comment has been minimized.

Show comment
Hide comment
@jedyang

jedyang Aug 9, 2017

作为一个刚接触前端的后端开发,仔细看了文章和评论,长知识了。感谢

jedyang commented Aug 9, 2017

作为一个刚接触前端的后端开发,仔细看了文章和评论,长知识了。感谢

@Summer120

This comment has been minimized.

Show comment
Hide comment
@Summer120

Summer120 Aug 12, 2017

非常有启发

Summer120 commented Aug 12, 2017

非常有启发

@lonelycheng

This comment has been minimized.

Show comment
Hide comment
@lonelycheng

lonelycheng Aug 15, 2017

如果可以把前端到后端的每一项技能要求都减少一些,那么我们就可以称自己为全栈了。

lonelycheng commented Aug 15, 2017

如果可以把前端到后端的每一项技能要求都减少一些,那么我们就可以称自己为全栈了。

@Blackgan3

This comment has been minimized.

Show comment
Hide comment
@Blackgan3

Blackgan3 Aug 19, 2017

详细的讲解了前端的发现历程,很感谢

Blackgan3 commented Aug 19, 2017

详细的讲解了前端的发现历程,很感谢

@finmily finmily referenced this issue Sep 22, 2017

Open

web架构 #1

@abnerlinan

This comment has been minimized.

Show comment
Hide comment
@abnerlinan

abnerlinan Nov 16, 2017

abnerlinan commented Nov 16, 2017

@Ghohankawk

This comment has been minimized.

Show comment
Hide comment
@Ghohankawk

Ghohankawk Mar 7, 2018

这句写的最精彩,回顾历史总是让人感慨,展望未来则让人兴奋。

Ghohankawk commented Mar 7, 2018

这句写的最精彩,回顾历史总是让人感慨,展望未来则让人兴奋。

@HalfWater

This comment has been minimized.

Show comment
Hide comment
@HalfWater

HalfWater Apr 8, 2018

@calidion
你好,您和yiakwy提出的很多问题的确是一针见血,几乎是从根基上否定了博主的观点。
第一次接触Restful API的时候,我也被其中那些佶屈聱牙的描述弄晕了,为什么不像你提出的Vig API一样简洁呢?

但是在工程实践上,对于阿里本身而言,如此多的工程师,能力有高有低,良莠不齐,或许第五张图代
表的实践方式能趟出一条路。
至于选择nodejs,我的理解是因为前端工程师用JavaScript比较多的原因,所以选择了nodejs。

至于对错,让上帝的归上帝,凯撒的归凯撒。真能解决工程中的问题,有些人并不在乎对错。

江湖之中,本来就是名望大的人说出不正确的话时,流毒甚广,所以孟子说“人之患在好为人师”。

我是一枚小菜鸟,望您轻拍砖头。

HalfWater commented Apr 8, 2018

@calidion
你好,您和yiakwy提出的很多问题的确是一针见血,几乎是从根基上否定了博主的观点。
第一次接触Restful API的时候,我也被其中那些佶屈聱牙的描述弄晕了,为什么不像你提出的Vig API一样简洁呢?

但是在工程实践上,对于阿里本身而言,如此多的工程师,能力有高有低,良莠不齐,或许第五张图代
表的实践方式能趟出一条路。
至于选择nodejs,我的理解是因为前端工程师用JavaScript比较多的原因,所以选择了nodejs。

至于对错,让上帝的归上帝,凯撒的归凯撒。真能解决工程中的问题,有些人并不在乎对错。

江湖之中,本来就是名望大的人说出不正确的话时,流毒甚广,所以孟子说“人之患在好为人师”。

我是一枚小菜鸟,望您轻拍砖头。

@JayVae

This comment has been minimized.

Show comment
Hide comment
@JayVae

JayVae Apr 21, 2018

nodejs作为中间层到底处理什么,还是不太明白……希望您能点拨一下~~

JayVae commented Apr 21, 2018

nodejs作为中间层到底处理什么,还是不太明白……希望您能点拨一下~~

@calidion

This comment has been minimized.

Show comment
Hide comment
@calidion

calidion Apr 21, 2018

@HalfWater

既然不需要区分对错。
我就是不必拍你了。

但是我希望你能找对你妈,别拿所有的女人都当成你妈才好。
也许你可以将你的妈当成是你女朋友。
因为你不在乎对错。对于你来讲,你妈与你女朋友是一样的。

也许是我理解错了。

你可能都分不清自己是人还是不是。

反正你无所谓。

calidion commented Apr 21, 2018

@HalfWater

既然不需要区分对错。
我就是不必拍你了。

但是我希望你能找对你妈,别拿所有的女人都当成你妈才好。
也许你可以将你的妈当成是你女朋友。
因为你不在乎对错。对于你来讲,你妈与你女朋友是一样的。

也许是我理解错了。

你可能都分不清自己是人还是不是。

反正你无所谓。

@HalfWater

This comment has been minimized.

Show comment
Hide comment
@HalfWater

HalfWater Apr 21, 2018

HalfWater commented Apr 21, 2018

@calidion

This comment has been minimized.

Show comment
Hide comment
@calidion

calidion Apr 21, 2018

@HalfWater

你不是不分对错吗?

你怎么知道是在骂你还是在夸你?

你能分清吗?

你不分对错的精神在那里呢?

智障果然很容易被证明。呵呵。

我说的当然不止你一个人。因为智障还是很多的。

多骂几个我也不会介意的,如果你还有智力能分出来这是骂的话。

calidion commented Apr 21, 2018

@HalfWater

你不是不分对错吗?

你怎么知道是在骂你还是在夸你?

你能分清吗?

你不分对错的精神在那里呢?

智障果然很容易被证明。呵呵。

我说的当然不止你一个人。因为智障还是很多的。

多骂几个我也不会介意的,如果你还有智力能分出来这是骂的话。

@HalfWater

This comment has been minimized.

Show comment
Hide comment
@HalfWater

HalfWater Apr 21, 2018

HalfWater commented Apr 21, 2018

@calidion

This comment has been minimized.

Show comment
Hide comment
@calidion

calidion Apr 21, 2018

一秒变成狗系列。呵呵。

果然又恢复了人狗不分了。

原来不分对错确实有好处啊。

身份可以随意的切换。

难怪这么多人喜欢不分对错。

要讲道理,分对错脑容量就不够,变成疯狗后脑容量刚好满足要求。呵呵。

既然都已经成犬了,就不必在意什么文化了。你估计人声与狗声都分不出来吧。

建议好好享受不分的乐趣,做一只快乐的狗人。

calidion commented Apr 21, 2018

一秒变成狗系列。呵呵。

果然又恢复了人狗不分了。

原来不分对错确实有好处啊。

身份可以随意的切换。

难怪这么多人喜欢不分对错。

要讲道理,分对错脑容量就不够,变成疯狗后脑容量刚好满足要求。呵呵。

既然都已经成犬了,就不必在意什么文化了。你估计人声与狗声都分不出来吧。

建议好好享受不分的乐趣,做一只快乐的狗人。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment