我们有一个 Cognito 用户池，我们希望将其迁移到新的用户池以利用一些不同的配置。但是，我们的池包含通过电子邮件、Google 和 Facebook 注册的用户。
我了解如何迁移电子邮件/密码帐户，但我不了解应如何迁移社交帐户。
从这个问题中，我可以看到没有办法使用不同的身份验证流程，所以我猜社交帐户也存在一些限制？
我们想到的一种方法是实际手动导入社交帐户。这是将社交帐户迁移到新池的正确方法吗？是否有不同的“AWS 赞助”方法？任何帮助，将不胜感激！
谢谢！
我已经包括了一些链接以及我们对其他答案的使用方法，这些链接似乎是目前网络上最理想的。
我们的记录需要分类（例如，“恐怖”，“惊悚”，“电视”），并且可以在特定类别和所有/某些类别中随机访问。我们通常一次需要访问大约20-100个项目。我们的类别数量也很少（少于100个）。
我们将数据写入数据库以上传/删除内容，尽管这是分批完成的，不需要实时。
我们尝试了两种不同的方法，以及两种不同的数据结构。
简而言之，将类别用作哈希键，并将UUID用作排序键。生成一个随机UUID，使用大于或小于1的值来查询Dynamo，并限制为1。AWS员工甚至在第二个链接中建议这样做。（我们还尝试过增加对所需项目数的限制，但这增加了查询第一次失败的可能性）。
这种方法的问题：
我们还考虑过为每个类别添加后缀，以人为地增加我们拥有的分区数量，如以下链接所示。
亚马逊网络服务：我们如何从dynamoDb的表中获取随机物品？
与此类似，我们将类别与序列号连接起来，并将其用作哈希键。例如horror-000001。
通过了解每个类别中的记录数，我们可以对整个数据集执行随机查询，同时还避免了热分区/键。
这种方法的问题
两种方法都可以解决我们对类别进行随机查询的主要用例，但是它们提供的缺点实际上阻止了我们使用它们。我们更倾向于使用后缀来解决热分区问题的方法＃1，尽管对于失败的查询，我们需要额外的重试逻辑。
有没有更好的方法来解决此问题？专门寻找能够很好地扩展（无需扫描）且无需实施额外资源的解决方案。＃1符合要求，但是需要管理后缀和失败的尝试确实阻止了我们使用它，尤其是当它在lambda中被调用（根据使用时间计费）时。
谢谢！
在 Nest 中构建 API 时，我经常遇到一个问题，即特定 API 可能需要使用多个 Nest 模块来完成其工作。我想知道是否有更好的方法来构建我的模块，以便更轻松地对其进行单元测试。
例如，假设我们有一个OrderService. OrderService为了完成它的工作，它使用了一些不同的依赖项：
ProductsService来查找产品详细信息和价格。UsersService来查找客户信息，例如 Stripe 客户 ID。Order写入数据库CouponsService来查找和验证 的优惠券详细信息Order。为了这个例子，我们假设这 4 个依赖项都是它自己的 Nest 模块。
当涉及到单元测试时OrdersService，我需要删除 4 个不同的依赖项。这似乎比应有的工作量多得多，所以我意识到必须有更好的方法。
我尝试做的一件事是创建单独的帮助程序文件来设置每个服务模拟。这减少了使用特定依赖项的每个服务的样板数量，但最终仍然会遇到 1 个服务可能有 4 个不同依赖项的情况。
理想情况下，我想实现某种模式或结构，以便在测试文件时，依赖关系要么非常简单，要么自动模拟，或者特定文件一次仅具有 1 个依赖关系，而不会过度简化系统。
我的问题实际上可以归结为：
如何在服务中处理像这样的许多依赖项，而又不会出现测试函数需要模拟 4 个以上方法的情况。我很想听听 Nest 的具体方法来做到这一点，但我也很欣赏任何通用的软件工程示例或模式来研究。