做模板渲染。其他一些访问控制、

node 控制 view data，java/php 提供 data servie，职责不一样

你也可以直接用node作为后端啊，但是有很多场景可能node是不擅长的，就需要用其它语言来做，然后用node去调，node作为中间层，对前后端分离比较友好，你可以自行百度node 中间层

微服务中API网关的作用，做外网统一的入口，也可以加入很多功能。

你可以先按你的想法做，网上的不一定都适合你的情况。

看你的具体场景，一些页面涉及比较多不同服务的情况下，用API网关会有一些优势，如果是很简单的需求，就没必要了

不谈场景聊架构是耍流氓。

为啥前端不直接调用java或者php呢

举几个场景：

• 如果你需要 SEO，服务端渲染?
• 如果你的后端是微服务的，他们坚持原子化，提供几十个接口，而且接口里面还有很多用不到的字段，你在前端如何处理？

关键问题在于，你要有一个服务自治的 BFF 粘合层，至于它是什么语言，无所谓。

Node.js作为一个“后端服务聚合平台”。在Node.js的后面，能够有

1. 数据库
2. Solr
3. Redis
4. 第三方服务商。比如，百度API，CNode的web API，或阿里的大数据API。
5. 你们公司自己的 特色 后端服务组件。比如说，基于OpenCV的《人脸识别》。

中间干嘛要加上一个node

1. 这个人不会 java / php 。
2. node 在某些方面，开发效率比 java 高。

现实中，大部分是第 1 种情况。

node这个时候的作用在哪？

作用在于你想怎么用它，或者不用它。没什么特别的啦，别想太多。

@atian25 哥，这图是哪里来的，分享一下来源，好呗？太有逼格了。

@yszou 还有一种情况，使用Node.js的话，一般就把前端也一起都做了（技术相通）。就天津的公司来说，还没有只做中间件的岗位。

@stuartZhang 我之前做的，可以看下 Egg & Node.js 从小工坊走向企业级开发

@stuartZhang

你想多了，没有什么“技术相通”的，语言语法这点东西，跟领域知识比起来，是微不足道的。 能把前端一起做的，是因为本来就会前端，而不是因为后端用了 nodejs ，换句话来说，即使后端用 java / php ，前端一起做也是一样的。 我一直觉得，能从前到后做出完整的“网站”，是一名 web 领域开发者的基本素质吧。（后来这玩意儿被称为“全栈”，变得好像很稀缺了，扯远了）

@yszou 完整是一回儿事儿 质量和效率又是另外一回儿事儿。。。

@yszou 你们公司牛人多。我单位的JAVA程序员对html5技术栈（包括Node.js，他们认为这是同一锅里的肉）从 不屑一顾，到后来的 “很抵触”。让我很失望。他们对CSS几乎一无所知（为此还感觉很光荣），对GLSL从来没有听说过。写js从来都只使用var，也从不Babel预编译。 所以，我之前也发过一个贴子，提到过，他们以“过客”心态写出来的（仅）js代码，还不够，我后面给打补丁，与重构的。更重要的是，团队里，这样的开发者的人数比重还很重。你可以相像我的工作压力。 所以，我一直都很推崇node.js + html5。至少，对js少了一份“过客”心态。也会带有更多责任心地写的代码。 至于，node.js与html5中的js的相通程度，我以《Node.js技术资格认证》的为例来说明。其中有三分之二，不仅对后端开发，对前端编程也同样很重要。

前后端共通部分

1. Unit Testing 5%
2. Diagnostics (Basics, Debugging, Performance) 5%
3. HTTP(S)/TCP 11%
4. Events 9%
5. Error Handling 7%
6. Control flow (Async tasks, Callbacks) 10%
7. Package.json 5% （写gulp或webpack脚本时，也需要呀）
8. Javascript Prerequisites (Closures, prototypes, var/let/const) 6%
9. Security 5%
10. Module system (Scope) 6% （重点是CMD；这个主要看项目中的模块化技术选型了：CMD, AMD，ES6 Module）

仅微服务端部分：

1. Child Processes (Basics, no IPC/fork) 7% （前端对应技术是web worker）
2. Buffer and Streams 9% （前端对应技术是ArrayBuffer与Blob）
3. File System 7%
4. CLI (-E, -R, etc) 3%
5. Process/Operating System (no IPC) 5%

此外，只要不涉及“后端领域”的核心技术。比如，大数据，人脸识别，文本检索，等等。而仅只做一些添删改查操作。使用node.js与使用JAVA, Python没有什么区别。所谓的后端领域知识对“后端中间层 胶水代码”的权重是很低。因为“胶水代码”技术层次比较低，还远远达不到被领域知识影响的水平呢。要知道，目前就连内联数据库SQL语言都不用写了，直接上ORM了。于是，就一个胶水代码的开发者来说，DB就是一个（只能被间接接触的）黑盒子。我还真不感觉，缺DBA人才。至少，我单位里的JAVA程序员都挤破头地想转型做DBA。

另一方面，node.js程序员具有着更多得多的被公司进一步培养的潜质：前端开发呀。

@stuartZhang

所以，我一直都很推崇node.js + html5。至少，对js少了一份“过客”心态。也会带有更多责任心地写的代码。

好吧，如果是因为“人”的问题，那总是有道理。因为我确实没有“因使用的技术方案去改变一个人的态度”这样的经历。

同时，我不认为，因为后端用了 nodejs ，一个原来不会前端的人，让他去写前端，就会有更好的效果（领域知识更重要，而不是语言）。相反，针对 java 换成 nodejs 的后端，也许还有效率的好处，但是对 php 这种则完全没有任何好处了，对于一个不熟悉 nodejs 的原 php 开发人员来说的话。

所以，基于“改变人的态度”，去改变技术方案，我不认同的。

只要不涉及“后端领域”的核心技术。比如，大数据，人脸识别，文本检索，等等。

我理解的“后端领域”，其实不是这些，而是“网络编程”方面的东西， HTTP 协议， Socket API ，网络模型，ER 模型 这些，与应用层开发直接相关的东西。你提到这几个，对于一般的开发人员而言，仅仅是“使用工具”层面的要求吧，就像“会写 SQL” 与“了解 MySQL”之间的区别。

这方面，使用 node.js 与其它动态语言是没有什么区别的（使用是与静态类的语言，还是有些区别的），所以我说“语言不重要”。

另一方面，node.js程序员具有着更多得多的被公司进一步培养的潜质：前端开发呀。

这话是没错，不过我还真没碰到过这种例子就是了—— 从 nodejs 作后端开发入行。

重审一下，我说的是，因为后端用了 nodejs ，而认为前后端就更容易让一个人给都做了的想法，是不对的。一个人能前后都做，与后端用什么没关系，只是在于那个人原本会什么。引审一下，就是，前端去学了 nodejs 做后端，与后端学前端的一些东西，这两者没什么区别的，跟什么技术，语言也没有必然关系。

@yuu2lee4

不要想当然了。

前端独立，要体现质量与效率的前提，是多出来的人，说白了是资源的投入换取的回报。并且这个投入与产出比并不是太高，以至于并不是小团队玩得起的。

后端用的是动态语言 php / ruby / python 什么的，效率最高的方式就是一个人前后端一起做，直接套模板。（特殊情况是那种定制编辑器的重交互页面，基本上都是前端逻辑，不过这种场景不多）。

至于质量，其实不太好说的，没什么客观的标准。我自己的一个标准就是，一套代码维护个半年一年就要抛弃重来的，就别谈质量了。一套代码能持续维护三年到五年，再说吧。基于这个标准，你会发现，前端独立的，质量“惨不忍睹”。

@yszou

1. 我想通过影响 项目参与者的 知识结构，来间接地 影响 他们对一些 既定事物 的想法 与 态度。至少，能够让项目参与者了解：怎么能写出一套让人接受的JS代码。
2. 我宁愿后端使用Python与PHP。以我亲身经历，脚本类开发者对html5技术栈的 抵触心理 远比 JAVA要低得多。可能是因为开发体验相近吧。毕竟，JAVA的代码写起来太爽了。至少，从开发体验来说，JAVA开发者 可以认定 目前脚本的开发体验都是 垃圾。
3. 在我单位《ER 模型》一般都 由项目组的技术Leader都做好了。普通的开发者接触不到那个环节。相反，普通的开发者，直接拿着ER图，创建DAO类，自动化生成数据表了。唉，你看看：现在创建数据表都不用 Mysql客户端了。我都已经N年没有写过SQL了。一组DAO类，就在APP层自动完成了。至少，我单位不需要人人都是Leader水平。也不需要，人人都会画ER图，只要能看明白就行了。
4. 至于HTTP协议与Web Socket协议与SSE协议，这个是入行WEB基本知识要求，无论前后端开发者。
5. 现在学习html5，都要首先了解《预编译》与《打包》技术。而，目前哪一款《预编译器》与《打包器》不是基于Node.js命令行小程序的？所以，我说，大部分的html5开发者都 从Node.js开始的。

我认为咱们认知上的差别主要来源于：你们团队的开发者是“技术歧视心态”很少（可能，几乎没有）。另外，就是他们的学习能力更强。但是，我没有你那么幸运。

@stuartZhang 你对《Node.js技术资格认证》的分类是有问题的

@stuartZhang

我想通过影响 项目参与者的 知识结构，来间接地 影响 他们对一些 既定事物 的想法 与 态度。至少，能够让项目参与者了解：怎么能写出一套让人接受的JS代码。

理解的，我前面也说了，人的问题，总是有理的。

我宁愿后端使用Python与PHP。以我亲身经历，脚本类开发者对html5技术栈的 抵触心理 远比 JAVA要低得多。

这点确实，或者准确点说， java only 的人员，可以在你说的现象上比较突出吧。（有多种语言经验的，看待这些都很平淡了）

现在学习html5，都要首先了解《预编译》与《打包》技术。而，目前哪一款《预编译器》与《打包器》不是基于Node.js命令行小程序的？所以，我说，大部分的html5开发者都 从Node.js开始的。

这点我倒不认同，干活的本质是解决问题，我觉得直接在页面中写 js 作为开始比较好啊。前端的那套工程环境的事，不需要一开始就抛出来吓人。以前没有这些东西的时候，一样可以把一个网站，或者说一个页面做得好好的嘛。有一个过程好些。

@yszou 首先，我单位里的那些JAVA从来不承认他们是Java Only的。他们也能写JS的，虽然那个JS写得让我很郁闷。 其次，关于最后一点，与项目的技术选型有关，比如说，

1. React/Vue.js的选择，
2. 还有就是：在项目一开始，就需要决定 是否全面使用ES 6/ES 7语法。
3. 选择哪一种模块管理策略（AMD, CMD或ES6 Module）。

这些都离不开Babel,Webpack甚至Gulp/Grunt。基于Babel预编译的代码，即使不借助任何“类jQuery库”都能轻松兼容到IE 8。当前，前提是：别使用CORS或Service Worker的无法模拟的语言新特性。

至于，在网页里写js代码的事，我们webpack打包之后的代码都被内联到html页里了。但是，直接在html页里手写js代码的事，已经几乎没有了。可能是因为 JS模块化 的全面铺开的原因吧。目前，国内浏览器还没有能够直接认识ES 6 Module的能力，虽然Chrome 61已经能够支持script type="module"了。

@i5ting 狼叔，能具体点儿吗？我是参考：https://nodejs.org/en/foundation/certification/#exam-details

@7demo 模板渲染你现在主要用哪个？

@chapgaga 用的koa.js，至于模板引擎看喜好了，我用的是ejs.

@stuartZhang 说的很好啊!赞一个

@7demo 推荐handlebar.js很有逼格的。

@leavesdrift 直接在我的发言上点赞，行吗？那样的话，支持得更直接。我会有轻风浮面的感觉的。