amplify-cli VS amplify-js

Bug: Before continuing, we need to add some manual changes to the generated output since there is a bug in the 10.8.1 version of the Amplify CLI. To fix the issue, open the amplify/backend/predictions/identifyText<>/parameters.json file and add the following three key-value pairs to it:

AWS Amplify CLI - GitHub

If this is the first time using Amplify you'll need to install the Amplify CLI. This tool will help us setup and add Amplify's services.

This disconnection between the initial business cases of DynamoDB and Amplify can even be seen within the AWS teams themselves. [4] We don't believe any of them are to blame. The solo Front End Engineer bootstrapping a quick Amplify app for a PoC feels like a way different use case than a team of highly trained data engineers working on their Single Table Design for their micro-service. Amplify rightfully tries to offer an easy way to deal with storing data. And so it follows a standard SQL design with DynamoDB. This though leads to bad performance (original selling point of DynamoDB) or other limitations hard to anticipate.

Overall it is pretty clear and fine that Amplify focuses on PoC projects rather than production ones (with features like Geo-tagging [5] but no way to migrate data). However, when starting to get traction, it is a shame we need to completely eject instead of being able to extend because of lack of (boring but necessary) fundamentals.

[1] https://github.com/aws-amplify/amplify-cli/issues/10164

Unfortunately, and this is a bad look for AWS, Amplify still hasn't migrated to CDK v2, meaning they're still using the maintenance-only CDK v1, which is incredibly easy to break due to incompatible packages, and isn't getting any new features. Further, Amplify's implementation of CDK (I think it's the StackSynthesizer subclass) doesn't even support some of the most productive features of CDK like the ability to create a Lambda image from a Dockerfile. You have to define and push the image separately which misses the point of having the entire app defined within Amplify.

Hi u/recursivebob , can you please submit an issue to the Amplify CLI on Github using this link

Hi all, for a new project I need to create a web app and mobile app and would like to hear your opinion on what would be the right architecture. The architecture has two peculiarities, it needs: - a service for crawling/scraping and writing into a (document) DB - full search text support for the crawled/scraped data Since the budget for running is low and time is tight, I was looking into serverless and BaaS architectures. I like the idea of using a BaaS architecture so I was I thinking if Firebase or AWS Amplify are a good fit. Regarding the full search text, Firestore does not support full text search out of the box, but it is possible to use Elastic, Algolia, Typesense (https://firebase.google.com/docs/firestore/solutions/search). With AWS Amplify it's apparently even more easier - it appears that it can be directly connected to AWS ElasticSearch. Regarding the crawling/scraping, I could use e.g. EC2 instances. Now from the time perspective looks good, but not from the budget perspective. As I found here: https://github.com/aws-amplify/amplify-cli/issues/3860 an ElasticSearch Instance on AWS can cost 70$ for 2 hours!!! This is around the budget for a whole month... So what you guys would advice me? Are there any alternatives? How can I move fast with a minimal cost?

AWS Amplify code is open-sourced and could be found on GitHub at https://github.com/aws-amplify/amplify-cli. We could make use of the NPM packages deployed independently to recreate the functionality offered by the AWS Amplify CLI regarding the GraphQL transformers. The entry point for generating the Appsync resolvers could be found here and the class we are interested in is GraphQLTransform which takes as a parameter all the individual transformers and iterates over them to generate the GraphQL resolvers and the associated CloudFormation stacks for deploying those resolvers.

Can you check that issue: https://github.com/aws-amplify/amplify-cli/issues/6338

AWS Amplify - The AWS Amplify CLI is a toolchain which includes a robust feature set for simplifying mobile and web application development. The CLI uses AWS CloudFormation and nested stacks to allow you to add or modify configurations locally before you push them for execution in your account.

One note of caution, though: Amplify uses a frontend-only Cognito integration that stores long-lived, never-rotating refresh tokens in browser storage, where any XSS vulnerability would have access to them. A more secure approach is to implement a couple of backend API routes to store the refresh tokens in `HttpOnly` cookies instead, which I outlined here (option 1 in your case to support SSO). I'll probably open source a solution to do this early next year so we don't all have to keep reinventing this wheel (probably why AWS calls their conference re:invent).

I'm ramosbugs on GitHub (that comment is mine). If you subscribe to https://github.com/aws-amplify/amplify-js/issues/1218 I'll post a comment there once I release a solution.

Amplify also lets you host a backend, which it runs in Lambda functions. You don't have a lot of control over it, but it works well for its intended audience: People who wouldn't know what to do if they had a lot of control over their Lambda functions. Amplify also lets you consume other AWS services easily, through declarative and easy-to-use libraries. That way, you can consume Cognito or S3 from the frontend without knowing a lot about Cognito or S3. Here's the complete list of libraries for Amplify, and you can check the Readme of the JavaScript one as an example of its features.

Whenever I call Storage.put() inside my React Native (with Expo) application, I get an error of [TypeError: undefined is not a function]. Doing some internet digging, after hours of searching, I found only one other reference to this kind of error, and that is with the DataStore: https://github.com/aws-amplify/amplify-js/issues/10764

Hello! Can you please create a GitHub issue here for us to investigate this further? https://github.com/aws-amplify/amplify-js/issues

Thanks for bringing this up. This discussion on the project's github is equally insightful on the subject.

Amplify GitHub Issue

Bug: There is currently, at the time of writing, a bug in Amplify that does not allow us to use the voiceId “Kevin”, which we selected when creating the backend resources. Selecting the voiceId “Amy” works, so we will use that.