问基于第三方计费/订阅系统( SaaS )的ChargeBee应用设计

EN

我不认为ChargeBee总是返回订阅信息有什么问题，但这是否是“正确”的做法呢？如果是这样的话，我是否应该在登录时为用户缓存ChargeBee信息？

我不认为这里有什么正确的答案。但是，请注意，Chargebee有一个150个API调用一分钟限制。缓存可能是错误的来源，所以我更喜欢直接查询Chargebee，如果它是您的选择。

首先，请注意，我创建了切达，ChargeBee的竞争对手。

祝贺您决定使用订阅管理服务提供商。通常，人们建立自己的，然后后悔它以后..。

我想说的是，一般来说，您希望避免存储在ChargeBee上可用的任何东西，反之亦然。保持这种双存储同步可能会有问题。我不太熟悉ChargeBee如何适应商业应用程序的访问控制，但我猜他们会以您建议的方式获得信息。

您将希望避免在不合理的水平上访问他们的API。在每个页面视图上都会从上游请求当前信息的体系结构，这是很容易的。你已经考虑过了，看起来.以下是您可能会考虑的其他一些问题：

1. 在每个页面视图上调用上游API的开销会使您的应用程序对最终用户来说显得很慢。
2. 如果曾经有上游服务，如果不可用，你的应用也是如此。

使用基本的缓存机制来缓解这些问题是一个很好的方法。显然有很多方法可以做到这一点。一开始就把有效期缩短就行了。比如说，一个小时。你可以在这条路上加长。如果您想更进一步，假设ChargeBee支持webhooks，您可以考虑设置应用程序来侦听可能更改用户状态的相关钩子，并相应地使该用户的任何缓存失效。

我还用了一年多的条纹蜂，我觉得它是可靠的。我认为根据您的流程，您应该存储customerId，并在需要时存储订阅if和客户的一些基本数据。