条带-超出API请求速率限制-Firebase云功能

Question

假设我正在创建一个PWA（渐进式Web应用程序），用户可以在其中添加产品。 这些产品的价格从0.01欧元到1.00欧元不等。 我正在使用Stripe付款。 Stripe Order对象不支持动态价格，即时传递，没有任何引用（外键类型）。 要接受订单，Stripe需要引用SKU。 就我而言，此SKU将是产品的价格变化。 这意味着，要涵盖所有变体，我需要100个SKU，从1（0.01 EUR）到100（1,00 EUR）。 因此，对于在Stripe中创建的每个产品，我需要在Stripe中创建100个SKU。

我尝试插入200个产品的测试数据集，这意味着（200个产品+（200 x 100 SKU））= 20200个请求。 我从Stripe收到一个令人惊讶的“超出请求速率限制”错误。 少于创建记录的一半... :(

“超出请求速率限制”是问题的核心。

现在，插入过程如下（x 200）：

• 在Firestore中创建产品。
• Firebase云功能侦听器：
  • 在Firestore中插入了OMG新产品。 好吧，让我们：
  • 导入官方的Node.js Stripe和Algolia库
  • 在Stripe中创建产品以使其可计费
  • 使用Promise.all在Stripe中创建与该产品相关的100 SKU（这在某些情况下会导致速率限制错误，因为我的并发云函数实例使用相同的Stripe密钥，这意味着相同条带帐户）
  • 在阿尔戈利亚创建产品以使其可搜索

我需要解决此Stripe API速率限制错误的解决方案。 我有几种解决方案：

解决方案1：

能够在给定的时间内增加Stripe rate API限制。 不确定是否可行。

解决方案2：

能够使用不同的Stripe键，然后将其旋转，以执行管理工作，例如在Stripe中插入多个产品/ SKU。 最终在生产中，能够以编程方式为每个用户创建1个Stripe键，因此每个用户都有自己的限制。 不确定是否可行。

解决方案3：

减慢javascript中的插入过程。 不知道该怎么执行。 此外，云函数的JavaScript预算/限制为60秒。 所以我不能耽误太多。

解决方案4：

使用Pub / Sub（？）或Firestore触发器延迟工作例如，在Firestore中有一个整数，每个函数调用都会递增，并且同一函数会监听写入内容以重新递增编号等，直到该编号为止第100个SKU等于100。 该解决方案将按条带化顺序写入100个SKU。 不确定这样做是否真的会减慢工作速度，使其不会超出API速率限制。 另外，这样的解决方案将花费很多钱：仅针对一种产品，进行100多次Firestore写入，以及执行100多次函数调用来执行这些写入，这意味着对200种产品而言为20000 + / 20000 +。 那将是昂贵的。

解决方案5：

当用户付款时，执行即时插入。 付款请求API调用后，服务器端算法可能如下所示：

 Create order in Stripe If error 'No such sku...' catched { For each SKU { // Ideally filter here SKUs to create (only those in error) If price not between 1 and 100 { continue // Bad price, not legit } Create SKU in Stripe If error 'Already exists' { continue // no creation needed for that SKU } If error 'No such product...' catched { If productId does not exists in Firestore { continue // Bad productId, not legit } Create product in Stripe } Create SKU in Stripe } } Create order in Stripe 

最后一个解决方案可以完成这项工作。 但是，这可能会给用户执行付款带来一些延迟，这可能会增加压力。 另外，它可能会增加营业时间内的Stripe呼叫。 同时进行的多次购买可能会导致Stripe API速率限制错误，尤其是在配备精良的购物车中（例如，购物车中平均有30种产品，因此在最坏的情况下，付款期间有30+个HTTPS调用，乘以1000个用户= 30000个调用= >条带错误）。 对于给定产品，该问题可能会随着时间的推移而减少，因为一旦创建了SKU，便会确定地创建它。 尽管如此，由于会有新产品出现，所以每天创建时SKU为零的产品仍然存在问题。

你怎么看 ？ 你还有其他建议吗 ？

Answer 1

进行一些调整后的解决方案3和解决方案5效果最佳。

解决方案3：您可以使用异步模块的forEachLimit或队列将并发请求的数量限制为Stripe。

解决方案5：即时插入也是一个不错的选择，因为它不会同时在Stripe服务器上增加太多负载。 关于您在工作时间内会遇到相同错误的担忧，这是非常罕见的情况，因为Stripe API的构建可以很好地执行。 但是，如果您对此仍然有疑问，可以采取一个非工作时间添加SKU的后台流程 ，这将继续为您创建SKU，而不会遇到Stripe API速率限制错误。

解决方案6（修改后的解决方案5）：在购物车中输入产品时，它会及时插入，但还会向服务器创建一个额外的API请求，这将检查Stripe中是否存在SKU，如果没有，则在后台创建它在购物车付款发生之前。

Answer 2

解决方案6：

相同的想法（JIT），但将SKU创建从付款时间转移到了产品选择时间。 每次选择产品时，请尝试在Stripe中创建产品及其当前的SKU（价格变化）。 这样，Stripe调用应该在时间上更加分散。 也许它会以更多的API调用结束，因为我们选择产品的次数比我们支付的次数还多，因为用户可以选择和取消选择产品，所以他们在旅途中选择的产品可能比购物车中最终支付的总和更多？

解决方案7：

相同的想法（JIT），但SKU缓存在Algolia或Firebase中，因此我可以执行“此SKU是否存在？” 调用而无需查询Stripe，如果在create调用之前执行了存在性测试（我们不会盲目调用Stripe.skus.create（）），这将减少Stripe调用。 缺点是，Firebase和Algolia暴露在前端，因此SKU和价格也会太高，这是潜在的威胁来源，因此必须使用服务器专用的唯一索引。