哪一组API计入Firebase Auth API限制(每秒500个请求)? [英] What set of APIs count towards Firebase Auth API limits (500requests/second)?

问题描述

firebase身份验证文档显示，您只能进行Firebase Auth API调用每个服务帐户每秒最多500个请求&每个项目每秒1000个请求.

The firebase auth doc shows that you can only make Firebase Auth API calls up to 500 requests/second per service account & 1000 requests/second per project.

例如如果我使用Firebase Auth Admin SDK调用 getUserByEmail 或 updateUser ，这些操作是否计入API限制?

e.g. If I use Firebase Auth Admin SDK to invoke getUserByEmail or updateUser, do these operations count toward API limits?

如何使用 verifyIdToken API验证ID令牌?如果我的项目通过验证authIdToken来验证从客户端进入服务器的所有请求，是否意味着我的服务器的上限阈值将是每个项目每秒1000个请求 ，因为该服务器是下游服务之一，即Firebase身份验证，每秒最多只能接受1000个请求以验证身份ID令牌?

How about verifying id tokens using verifyIdToken API? If my project verifies all requests coming in to the server from clients by verifying authIdToken, does that mean that my server's upper scaling threshold will be 1000 requests/second per project because the server's one of downstream services, Firebase Auth, can only accept up to 1000 requests/second to verify auth id tokens?

Firebase文档似乎缺少与这些API限制有关的详细信息.

Firebase doc seems to be lacking details related to these API limits.

推荐答案

是的，1k/s包含了Admin API中的所有限制.我觉得如果下游只能处理1k/s，您总是可以实施退避或节流算法来处理更高的突发负载.我认为这些对于用户身份验证来说足够了，因为用户不经常登录.对于机器对机器，建议您使用其他身份验证系统.

Yes, 1k/s includes all limits from the Admin API. I feel if the downstream can only handle 1k/s you can always implement a backoff or throttle algorithm to handle higher burst load at times. I assume these are mostly sufficient for user auth as user don't login frequently. For machine to machine, I suggest you use a different auth system.

这篇关于哪一组API计入Firebase Auth API限制(每秒500个请求)?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！