AWS Cognito - 通過 Cognito API 或同步到單獨的數據庫中的用戶配置文件使用和更新

Question

我從 Cognito 和一個移動應用程序開始，其中除了其他核心功能外，還可以更新用戶配置文件並且經常查詢池。 因此，我正在考慮以下選項：

1. 直接從應用程序使用 Cognito API 查詢礦池
2. 使用 Cognito API 查詢池 - 可能是管理功能？ - 從后端 REST web 服務，基本上包裝 Cognito API 以確保可移植性和無供應商鎖定

要么

3. 根本不要將 Cognito 用於用戶配置文件數據，而僅用於用戶身份驗證。 在 MySQL 數據庫中創建一個表，其中用戶訂閱者作為 ID 和所有其他附加屬性，如他們的網站、照片、文本/配置文件描述等。在 Cognito 提供的 Lambda 觸發器的幫助下填充它。

雖然在選項 1 和 2 之間進行選擇是架構和戰略決策，但由於我不確定使用 Cognito Pools 的方式，所以出現了選項 3。

在了解AWS Cognito 的服務限制后，我選擇了選項 3。 我知道這些是可調的，但從允許每秒 5 次開始，我想知道這是否會在某個時候成為瓶頸……

任何已經使用 Cognito 構建了高效應用程序的人：

1. 您能否總體上分享您在 Cognito 服務限制和池 API 的性能方面的經驗（不僅僅是登錄/注冊）？
2. 僅將 Cognito 用於身份驗證/授權還是用於完整的用戶管理更好？

謝謝！

Answer 1

我們遇到過同樣的情況 Nikki。 我會推薦選項 3。其他 2 個選項會導致更多麻煩。

• 在某些時候，我們希望在我們的 lambda 中為用戶提供額外的數據，但這些數據不是 jwt 令牌的一部分。 我們想知道用戶的注冊日期。 收集的唯一方法是觸發其中一個管理 Cognito API——它運行良好——但是當流量顯着增加時，我們的端點出現故障，因為我們達到了adminGetUser的限制。
• 我們遇到的一個問題是，我們必須不斷地進行從 Cognito 到 Cognito 的數據轉換。 檢查 adminGetUser 的響應，您會發現這不是最好的響應。
• 我還記得的另一件事是，當我們想為用戶數據添加一個額外的字段並用特定值填充它時，或者如果您有要求必須檢索其中一個實體的列表並且將其與用戶一起加入，因為您需要在響應中顯示用戶元數據。 這將是一項極具挑戰性的任務。
• 一個簡單的任務，您可能想要發回帶有分頁和排序的用戶列表，這可能有點具有挑戰性。 您可以列出來自 Cognito 的用戶，但不能進行排序。

總的來說，我真的很喜歡 Cognito 在身份驗證、驗證電子郵件、社交登錄、應用程序客戶端方面的簡單性。 出於這個原因，它是完美的，但我不會在生產就緒環境中將用戶元數據保存在 cognito 中——除非它是一個小的概念證明。