请问下node做接口转发的意义在哪里? - CNode技术社区

公司使用的是express做接口转发,我最近自己也用eggjs写了点,发现接口请求的时间比直接请求多了一倍。在性能上没有一点提升,不知道还有什么用呢?为了不暴露服务端接口?如果是安全问题后端应该也有解决方法吧

灵活/高效/解耦

@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 image.png 像这一块,我自己用eggjs写的,合并多个接口的请求,返回组合的数据,这样请求时间就会增加很多,但是前端如果请求多个接口因为是并行的,其实请求时间并不是很慢。只是请求了多个接口。我就很纠结到底该不该用

你的写法有问题,for 循环里面是串行的。 看下 promise-fun

@hyx0217 你这写法不慢才怪呢。。串行执行,总时间是所有请求的时间合,你这必须串行执行?没必要的化用Promise.all,也可以使用async库

@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 再看