后端出于性能和别的原因，提供的接口所返回的数据格式也许不太适合前端直接使用，前端所需的排序功能、筛选功能，以及到了视图层的页面展现，也许都需要对接口所提供的数据进行二次处理。这些处理虽可以放在前端来进行，但也许数据量一大便会浪费浏览器性能。因而现今，增加node端便是一种良好的解决方案。
我之前多个项目的场景，前端渲染交给node来做，前端团队自己负责整个前端的发布构建，整个工作流使用gulp或者webpack搭建起来。业务团队是典型的java后端，他们有自己成熟的架构，node服务器通过thrift来做rpc调用。实践起来，两个团队配合相对比较和谐，相互独立。
这种场景比较适合前端爱钻研折腾，后端团队比较成熟，或者保守。
一般这种情况下，会将node作为一个中间层，这样传统的"前端-java"架构就变成了"前端-node-java"的架构。
这种架构的好处主要就是实现前后端分离。在传统的web应用中，java同时负责业务逻辑以及页面的服务器端渲染，这种架构下，前后端开发的模式主要是这样的：
1. 前端开发好demo页面（包括css，js，html）
2. 前端将css，js等静态资源交给cdn等静态服务器，而html文件则交给java后端，让后端将demo页面转为vm模板。用户请求时，java首先将vm模板渲染成html，然后再交给浏览器。
这种模式之下，由于后端对于前端知识的不熟悉，导致在html转换vm这一个过程中，前后端交流沟通的成本比较高，同时，这也等于束缚住了前端的手脚，让前端无法随心所欲的对页面进行一些个性化的优化，定制等等。
为了克服这种开发模式的缺点，最理想的情况是，java之负责业务逻辑，对外，它只提供api数据接口，剩余页面渲染相关的工作都交给前端来完成。
目前有一种方案是前端页面完全交给javascript来进行纯异步渲染，也就是说html文件也传到cdn上面作为静态文件，当用户请求的时候，页面中的数据通过js的ajax请求来渲染。这样做确实是实现了前后端分离没有错，但是缺点是，首先这种架构下，页面首屏渲染会比较慢，因为在加载好html之后，还要额外通过ajax请求数据然后才能填充页面；此外，由于搜索引擎的爬虫无法爬下js异步渲染的数据，导致这样的页面，SEO会存在一定的问题。
为了克服上述方案的缺点，业界提出了使用node作为中间层的方案。在这种架构下，模板都放在node端，当用户发起请求时候，请求首先到达node端，然后node向后端的java请求数据，拿到数据后填充渲染html模板，然后再返还给用户。这个架构下，浏览器端和node端都由前端开发人员来负责，java后端只需要处理业务逻辑并提供api接口，这样既实现了前后端分离，由解决了异步渲染中的种种问题。
目前很多公司都在事件这种架构，最知名的，当属淘宝的midway架构，楼主感兴趣可以关注一下。
2 node和java对比
事实上 Node.js 自身依然存在许多问题——就像许多其他竞争对手一样，但是目前在 Web 浪潮的席卷下，它的优势显然更被人们关注，而劣势则尚未在大多数项目中显现。
总的来看，Node.js 特别适合中小型系统的快速开发，而当系统变得复杂以后，Node.js 更适合充当 Web Gateway 的角色，以及用于前端开发。在这两方面它拥有绝对优势。
总结
