Will add more references for already existing open issues at the amplify/cli
The below bugs are present in CLI version 11.0.5. Due to the breaking changes introduced in newer versions, we have chosen to stick with this version. Additionally, I did attempt to upgrade to another version, specifically version 12 or higher. Although there were bugs that I addressed directly with AWS Support, they were subsequently fixed in newer versions. However, we decided not to proceed with future upgrades due to concerns about the stability of Amplify.
- Either fix query generation on the Amplify side.
- Provide documentation and use cases for custom JS resolvers.(Will provide an example)
- Include an advanced filtering example based on multiple relations (one-to-one, many-to-many).
- Don't forget about pagination. Note that the 'filter after' feature of OpenSearch causes issues.
The assumed role expiration token used via the Amplify console has a validity of 1 hour. If you have a large schema with multiple models and multiple @searchable annotations on them, the initial build may not finish within 1 hour. As a result, the token expires, and the build fails. I attempted to increase the token expiration time without success.
The workarounds are as follows:
- Allow the build to fail due to the expiration token. It will not rollback but will complete the building process without providing any feedback status on the Amplify console side. The subsequent build will succeed because the necessary services will be in place.
- Execute amplify add env/amplify push (first) from the local machine instead of using the Amplify Console.
When you add a custom pipeline resolver, you'll have to take care of authorization. For example, if you have group authorization and so on. There isn't any documentation related to how those authorization checks can be added. I had a call with AWS Support, and they provided some guidance.
The generated CRUD resolvers are okay, but not really helpful. They suffice for basic operations like add/list/update entities, but for a productive and important project, they will never be enough. Custom logic and checks are necessary. Unfortunately, there isn't any documentation other than examples of creating custom functions with custom business logic. It would be important to have documentation and use-case examples related to the following:
- Input validations for default resolvers (server-side).
- Authorization group use cases. There's a peculiar issue related to Amplify: imagine having 2,000 items in a table with different authorization groups on each entity, and you're using the owners array approach to retrieve only the objects which you own. Let's assume you own 10 objects, and these objects in the Dynamo table are positioned between items 600 and 900. Now, imagine you have a UI page that should retrieve items with pagination, and you have a page count of 10. When you call the listEntities API for a specific user with a specific group owning those 10 objects, you'll receive nothing back. This is because DynamoDB handles limits differently. It loops over all tables and retrieves the first 10 objects (even if you don't own them) with the first call, then the next 10 objects, and so on until it reaches 2,000. The filtering based on the owner array is done at the AppSync side, meaning you would have to call that API 2,000/10 times in order to receive all the items for that owner. The autogenerated queries are useless if you use owner field authorization, but the documentation says nothing about this. However, this issue can be addressed from the AppSync side within the Amplify framework.
- Also related to the owners array: the DynamoDB length limit for an array is 1,000. If an item has an array with more than 1,000 items (e.g., user IDs), it will fail to retrieve that item.
- Documentation for using AppSync API calls from a Lambda function (with IAM and Cognito Groups examples).
The documentation is incomplete, and we always encounter troubles when switching locally to another Amplify environment, such as:
The backend-config.json file is consistently modified with strange changes, often resulting in the removal of function environment variables.
- The
amplify-dependent-resources-ref.dfile also undergoes unexpected alterations. When runningamplify pull env, it consistently prompts users to set up theirproject-config.jsonsettings from scratch, including framework selection, source directory, etc. - Dealing with the
#current-cloud-backendfolder is consistently problematic. Perhaps some documentation would be useful regarding when to delete the entire folder and when not to.
- The Lambda Layers are not sufficient. While they address certain issues, what is lacking is documentation on how to utilize ESBuild to share services and models without copying them or relying on shared npm libraries.
This is a painful one. We had an incident in the PRODUCTION environment, and I've documented all the details here: https://share.1password.com/s#c9ndbYaPAghDL9zCgVRXqa0xWPFgLJ_GU-CpB2jifG4
But, in order to have a successful framework and assist the community, the Amplify team should add documentation for solutions related to how to perform backups, how to execute rollbacks, and so on for DynamoDB Amplify-related tables and Cognito user pool recovery (another painful aspect).
An automatic rollback (point in time), at least for DynamoDB and Cognito, directly within Amplify would be a dream, but it's not impossible to achieve. This would be a huge selling point.
Docs related to:
- How to enable data replication between Blue/Green environments
- Use cases and real-life examples
- Why it's important and why we need this? Let's assume you're deploying a new app version which uses Amplify for backend and frontend. The backend build succeeded, but the frontend one did not. The current status would be that the backend will not perform a rollback and will use the new version, while the frontend will still use the old version. If there are changes at the API level, issues will arise. What if you have thousands of users in production? Don't try to imagine. It's painful.
The Cypress docs already exist and are good. However, what is missing are:
- Integration test examples.
- Unit testing for Lambda functions (Mocking the Lambdas when you have @searchable or Lambda Layers is also a pain). Methods for running these unit tests in the pipeline.
This is actually a best-practice pushed by AWS.
The current implmentation of Amplify is to use DyanamoDB in a relational database fashion. This is an anti-pattern for NoSql.