I am starting with Cognito and a mobile application where, along with other core functionalities, user profile can be updated and the pool gets queried quite often. Therefore I am considering following options:
- Query the pool with Cognito API directly from the app
- Query the pool with Cognito API - probably Admin functions? - from the
backend REST web service , basically wrap Cognito API to ensure the
portability and no vendor lock in
OR
- Do not use Cognito for the user profile data at all, but only for user authentication. Create a table in a MySQL database with user subs as IDs and all the other additional attributes, like their websites, photos, text / description to the profile, etc. Populate it with help of Lambda triggers offered by Cognito.
While choosing between option 1 and 2 is rather architectural and strategical decision, option 3 popped due to my uncertainty of ways to use Cognito Pools.
I came to option 3 after finding out about Service Limits of AWS Cognito . And I know these are adjustable, but starting with allowed 5 per second I am wondering if this wont become a bottleneck at some point..
Anyone who already have built a productive app with Cognito:
- could you share your experience with Cognito Service Limits and performance for Pool API in general (not just sign in/ sign up) ?
- Is it better to use Cognito for authentication / authorization only or for complete user management?
Thank you!
We have faced the same situation Nikki. I would recommend option 3. The other 2 options will cause more troubles further down the line.
- At some point, we'd like to have extra data for the user in our lambdas but these data were not part of the jwt token. We would like to have the registration date of the user. The only way to collect that was by firing one of the admin Cognito APIs - which worked fine - but when the traffic increased significantly our endpoints were failing because we were hitting the limits for the adminGetUser.
- A problem we had was that we had constantly to do data transformations from Cognito and to Cognito. Check the response of the adminGetUser and you'll realise that it's not the best response to work with.
- One more thing that I can remember is that when we'd like to add an extra field for the user data and populate it with a specific value, or if you have a requirement where you have to retrieve a list of one of your entities and join it with users because you need to display user metadata in the response. This will be an incredibly challenging task.
- A simple task where you might want to send back a user list with pagination and sorting it can be a bit challenging. You can list the users from Cognito but no sorting.
Overall, I really like Cognito's simplicity with authentication, verification emails, social logins, app clients. It's perfect for this reason but I wouldn't hold user metadata in cognito for a production ready environment - unless it's a small proof of concept.