关于前端引入node.js作为与后端通信的中间层一点小问题

Question

二话不说先上图，问题如下列表，望各位大大解解惑。为了防止防止跨频道回答，首先先说说自己对于前后分离的理解，后端管理model层，业务处理/数据等，前端负责view or Controller层（例如表单提交之后的跳转等）,举个例子来说，假设目前有一个SPA应用，在开发过程中后端仅提供API（对于Controller层和view层不管理），所有前端的页面展示，跳转等都是有前端自己控制，而前后端通信的唯一方式就是API。问题如下假设目前有一个列表直接用node请求，渲染模版最终展现页面，和直接在页面发起ajax请求，然后用js渲染页面，会不会由什么区别（不考虑SEO的情况）假设我现在有一个表单的提交，一般情况都是调接口拿到返回值再作出对应的操作。在node作为中间层的情况下是调用node的服务，然后node调用后端的服务（例如：API），这样和前端直接调用api有什么区别？node作为中间层的前端架构体系的优势以及短板分别有哪些？（类似于seo，前后分离专业的人干专业的事可以不用说，感觉网上的东西太散了，每个全局的视野）

Answer 1

1. 最后的结果没区别。但是如果你对时间要求很高的话，我建议是服务端渲染，比如页面缓存。而如果要求不是太高的话，我更倾向于前端渲染（开发方便很多），SEO可以通过ua返回一个完整页面，不是太大的问题。

2. 这样前端就不用关心后端服务，不用发送一堆请求然后组合出需要的视图数据，这部分都交到node上做，后端变更也只需要同时更新node服务。

3. 短板暂时没想到。等大佬指出。

补充

看到楼下的回答想起了耗子老师的一篇文章分布式系统架构的冰与火
问题3的逻辑大致相同

Answer 2

1。有条件使用node当然要加上node啦，可以不暴露前端设计结构，更符合架构思想啦。
2。继续推广微服务架构，使用node做中间层，便于模块化处理啦。
3。短板很明显，增加基友们的开发复杂度和闹心程度，业务的维护就增多。但是很架构，很有设计模式的思想啦。
4。港声多谢乌蝇哥啦?。

Answer 3

Q1:如果只是一个列表的话，没什么大的差别吧。用node.js渲染返回html可以有良好的首屏体验。但是如果列表分页的话你又要一次完整的页面加载。这个时候ajax就可以避免这个问题。首屏体验可以由前端技术优化。服务端渲染最终吃的是服务端的配置和性能。大访问量下如果把渲染交给前端，你的服务器减轻很多压力和配置上的节省。
Q2:区别
增加了一层node作为中间层很明显就多了一层网络请求。nodejs启动了一个web服务器。你的Ajax请求本来是由：
前端=>nginx=>应用服务器(Java/Server)
现在多了一层就变成了:
前端=>nginx=>nodejs中间层=>应用服务器(Java/Server)
负面的情况下：如果傻傻地把node.js中间层部署在了和应用服务器完全不一样的环境。这一层网络请求会影响请求效率。如果部署在了同一个环境则影响变小。但依然有影响。
正面情况下：nodejs中间层提供了你整合接口的能力。面对多变的前端业务变化。你可以灵活整合自己所需的接口。
Q3:整体如果能实施的话感觉还是利大于弊的。多了个中间层对前端人员要求的增加(人员成本)，维护成本的增加(单元测试，测试成本)。甚至某些时候排错的影响。本来的业务逻辑出错可能在前端，不然就是后端(数据库，运维层面的也包括)。现在还可能隐蔽的出现在中间层。好处我感觉就是灵活度和可维护性。接口对前端来说似乎更友好更稳定了。

以上都是个人见解，有错误还请帮忙指出，因为还没实践过node.js中间层。