公司使用的是express做接口转发，我最近自己也用eggjs写了点，发现接口请求的时间比直接请求多了一倍。在性能上没有一点提升，不知道还有什么用呢？为了不暴露服务端接口？如果是安全问题后端应该也有解决方法吧
回复 (19)
灵活/高效/解耦
@zhangshichuan 不太理解，前两个没体会到，只是增加了工作量，最后一个如果跟后端约定到restful api风格就可以了吧。 个人理解node如果做中间层，目前最大的作用就是做SSR，做接口转发我觉得完全没必要
这个都是看业务。但也有很多公司就是为了中间件而中间件，学其皮囊弃其灵魂，没软用还加组件
@hyx0217 看场景，尤其是大项目，后端 C++ java 都这么写接口的话会累死。 场景一： X宝，大后端是 java 为主，支持基础业务。 中间一层 node.js ，比如618 ，双11 各种形形色色的活动，后端的基础业务其实不变，这块用 node 快速开发 非常合适。 如果你是用 java 写这些玩意，估计等你写出来双11，双12 都来了，需要灵活快速的脚本语言。 场景二： graphql 生态，可以自己去搜。 场景三： SSR 不多说。
小项目没必要！ 小项目没必要
@zuohuadong 刚刚研究了下graphql，node做接口转发可以使用这个吗？这样如果可以把后端提供的多个接口合并起来，也是个使用中间层的优点
我们这边 bff 做 统一鉴权。 有些复杂的接口在bff做组装、清洗甚至缓存。 有些简单的接口确实有点多此一举的感觉。 看实际情况了。
发现接口请求的时间比直接请求多了一倍。
大概率是你的写法有问题，是不是同步了。
在性能上没有一点提升，不知道还有什么用呢？
主要在于解耦，通过服务自治来提升协作效率。如果你们后端的发布频率足够快，足够配合你们的任何需求，其实不用中间层也无所谓的。
这一层叫做 聚合层，简单理解为 Java 时代的 MVC 层，只不过现在很多团队会把这一层交给前端，然后前端会更倾向于用 Node 来实现。
@Gitforxuyang 我们公司也是，鉴权都放在node端了，那这样后端那边不就都不用做了？还有那种复杂的接口比如在node组装请求多个接口合并成一个，或者其他的操作，这样是不是大大增加前端请求接口的时间。
@atian25 代理的请求我都是用async await来写的。每次请求打印控制台消息，这个好像也会影响，不知道有没有好的模板给我学习下写法。
@atian25
像这一块，我自己用eggjs写的，合并多个接口的请求，返回组合的数据，这样请求时间就会增加很多，但是前端如果请求多个接口因为是并行的，其实请求时间并不是很慢。只是请求了多个接口。我就很纠结到底该不该用
你的写法有问题，for 循环里面是串行的。 看下 promise-fun
@atian25 大佬是说的是用promise.all()是吗，我这样写是因为promise.all返回数组是根据响应时间来排序的所以用这种写法。请问下大佬要是用eggjs做类似这样的接口转发，请求时间一般来说还是有影响的是吗？毕竟中间加了一层，不过中间层其他的优点，这样的影响是否可以忽略不计了？
@HelTi 我明白，我之前也是promise.all写法，只是返回的顺序不一致,尴尬，我有其他思路了可以就是用promise.all，用映射标识每个请求对应的数据就行了，
@hyx0217 是的。 我们原来就是各个微服务自己做鉴权。不好。 所以统一在bff层做。 至于你说的组合多个接口请求耗时会增加。我只能说在理论上只增加了一层http连接的时间。 在我们实际使用中。这一层消耗的时间不超过10ms。 可以说是可以忽略不计。
@hyx0217 可以看下 https://github.com/sindresorhus/promise-fun 提供了很多 Promise 的上层封装。
你这种场景一般用 p-map 来搞，可以设置并发数。
请求耗时是几乎可以忽略不计的，唯一的风险就是多了一个节点肯定不可避免会多了运维上的保障点
@hyx0217
我这样写是因为promise.all返回数组是根据响应时间来排序的所以用这种写法。
Promise.all 的返回值, 不是应该是 根据 传入的 Promise 来排序的吗?
@zhangxh1023 不好意思，刚验证了下是的，太笨了这都记错了
@hyx0217 你这样是串行的，改成 Promise.all 再看