I’ve heard some people complain about AWS Cognito’s complexity, but I’ve had the opposite experience. I’ve never done on-boarding before, and every project I’ve ever been on, or near, on-boarding was always a horror show, both in UI, ability to debug, and stability.
I haven’t had the opportunity to integrate with it on the back-end yet (e.g. Lambda functions after sign up/login, etc), but on the UI, I’ve had 2 projects using it now over a year’s experience. I like it.
The hosted UI aspect of Cognito is a massive accelerator in terms of getting our application working. Yes, the token in fragment is a bad security thing, but when we’re prototyping ideas with 1 or no users, it’s amazing. Just 2 URL’s and the entire user experience around login, logout, forgot password, reset password, sign up, and the plethora of error messages for all the use cases for the most part are accessible in your code so you can either handle it yourself, or show your user(s) so they can help you/the admin debug what’s going on.
On the flip side, the API’s to call Cognito if you’re building your own UI are pretty straightforward too. I’m using the Elm ones which they wrapped the standard AWS REST API, but if you’re a JavaScript dev, if you’re willing to ignore all the Amplify “why are we using Amplify code when we’re using Cognito!?”, it’s also great. Docs are a bit obtuse as they deviate from the AWS docs norm, but DO get you running in a reasonable time as well.
Also, both the AWS, and Amplify docs, give you various options on security posture, and the API’s match their docs so you know what you’re going to get, and what to code for. Given on-boarding can be quite complex because a user can be in many states (not signed up, signed up, unconfirmed, etc) and they can arrive in your app from many places, and their tokens can be working, invalidated, outdatedā¦ it can be a challenge as a UI dev and Designer to wrangle the user experience when a user is like “Dude, I just want to loginā¦”
Overall I really enjoy this service, look forward to playing with the server-side integrations in the future, and recommend it. If you’re new to UI Development or UI Design, I highly recommend you run for the hills as it is hard and complex, especially if you want to the user experience to be awesome for the user. I have a massive new appreciation for on-boarding. People have told me in the past that it’s hard, and boy, I had no idea. AWS did an awesome job here of abstracting away the security and complexity so you can quickly build experiences.
The only negative feedback is Amplify seems to be attempting to dominate the front-end space, and I don’t think it’s working. Instead, they should have the standard AWS docs like they have now continue to provide the AWS Node.js SDK information, but also continue to support the AWS Browser SDK. Some of the API design in Amplify is much more well thought out, more browser/node.js/javascript/ui developer friendly than the AWS Browser SDK is which is often just a 1 to 1 matching of the Services (if you know the Service and have AWS SDK experience, you can ramp up on a new service quickly). However, the browser is always a special beast “because security” and “because UI state”.
Second, I wish they’d pull, somehow, that Amplify Cognito related API’s into the AWS Browser SDK instead of this special one of. Maybe I’m not much of an influencer, but despite singing Amplify’s praises, there are just a contingent of AWS back-end and Ops people who are like “S3, CloudFront, and API Gateway work fine, leave me alone”. :: shrugs ::
Third, it’s confusing af using Cognito in Amplify when I’m not using Amplify, not using the Amplify CLI, but referring to Amplify docs. I think it’s less of a Branding problem, and more of a Kingdom Building problem maybe?
I think my biggest learning is if this happens again, I may just follow the elm-cognito lead and build my own API layer atop the AWS REST API’s I need vs. Minecrafting into Amplify lands for Cognito fruits.
tl;dr; Cognito, highly recommend to UI folks.