(Comment based on experience from an earlier version)
I tried it a while ago (more than 1yr ago) and was taken aback by the number of AWS constructs it uses. I wasn't sure what all it was creating on the backend and what the impact of those constructs on the product's recurring billing would be. As-is the cloud abstraction makes it a bit difficult to know (i.e., estimate) what your operating costs are going to be (without using some tools). The Amplify toolset while well-intentioned and already bakes in a lot of AWS guidance/best practice, you feel a loss of fine-grained control over your application's architecture and that was the reason why I did not use it.
It may make sense to use it for certain category of apps where you don't have heavy load (i.e., high opex). The speed of development is certainly helpful for prototyping. But, as others have mentioned, the biggest downside comes from the loss of fine-grained control and when you need to go outside of the Amplify framework to integrate or add stuff, it can become a challenge.
They may have addressed some of these issues in the latest version. I will have to try it out though.
> As-is the cloud abstraction makes it a bit difficult to know (i.e., estimate) what your operating costs are going to be (without using some tools).
I frequently wonder if this is by design. When you prototype/launch, these are zero or so close to it that you can ignore them. By the time you have product/market fit and start to scale, you are too busy to replace the expensive and tightly-coupled backend with something more cost-effective.
It's not really a bait and switch, but it's really the worst kind of insidious lock-in.
> I tried it a while ago (more than 1yr ago) and was taken aback by the number of AWS constructs it uses. I wasn't sure what all it was creating on the backend and what the impact of those constructs on the product's recurring billing would be.
This is common for AWS sales demos. In this case there are cost externalities, but I'm more used to caring about authn/authz externalities, where the flashy demo makes you think "it's so easy" but then you get into the nitty-gritty of making sure that whatever thing is safe to deploy in a production environment.
You have to dive very deep into AWS docs and forum posts (hopefully, but less likely if it's a newer AWS product) to find all the ways to limit access to the thing and especially by the thing, especially since so many AWS demos come with IAM policies that are littered with asterisks.
In my experience this is a superb way to rapidly create bad integrations with AWS.
Some of the simple things will be easy, everything else will be hard.
Also instead of supplying an SDK, Amplify will provide components that can seriously constrain lots of your UI architecture decisions.
For Javascript the old mobile SDK was much more usable.
Almost all of the AWS services have a sensible JSON API, I wish that AWS would just generate sensible SDK bindings for Swift, Javascript and Dart and stop all development on Amplify.
> Note: Following the steps below will restore your Amplify resources such as DynamoDB tables, API’s, Amazon Cognito Userpools, etc.; but not necessarily restore the content within those resources (i.e. database entries, files, users, etc.)
Unbelievable.
Anyway, I happened to be working on my first Amplify-based project just this last couple of weeks so I have some pretty recent experience exploring the various features of this tool. Here's a bit more context:
One thing that is important to understand is that Amplify is split into "hosting" and "studio". I found Amplify Hosting to be pretty well done - you connect a git repo to an "amplify app" and when you push to that repo amplify will build your code and deploy it. I'm using it for static websites, so this means running a few npm commands and whatnot. They handle 100% of the build environment, I don't need to provide a role or docker image or anything. One key feature is that, upon pushing a git branch, amplify hosting will automatically create a new environment with your code deployed within it at a unique URL for the developer to evaluate their changes in.
Adding a "backend" to an environment actually means you get an instance of Amplify Studio. You can see a screenshot of Amplify Studio in the OP and there in the sidebar you can see the list of things a backend provides - Auth, A graphql api, a rest api, functions, and others. Here's where thing's fell off for me - the intended use of Amplify Studio seems to be to click around in the UI or use the CLI. You can create an app and backend via cloudformation or other APIs, but there don't seem to be published APIs to populate how the backend is configured.
Behind the scenes, amplify studio creates a cloudformation stack in your account and, as you click around in the studio UI or use the CLI, creates nested stacks with related resources, like a cognito pool if you turn on auth.
All in all, I think it's a flashy product that looks very attractive to web or app developers. To those that need to consider business continuity, it looks like a nightmare.
If Amplify (the backend that's behind Amplify UI) would generate human readable terraform / high level CDK constructs, so you can prototype fast with Amplify, but then use infra-as-code for deploying, I would have trusted it much more for any production grade project. Also if you could replace Cognito with let's say Auth0 as the authentication layer, would also be amazing.
Has it been updated? Last time I gave this a spin (within the past year), the UI was buggy as hell. I was really excited to use it for a personal project but it did not quite deliver on what it promised.
It’s probably ok if it’s a couple of years old. All AWS stuff is initially buggy as hell. You have to complain for a year at your account manager to go and beat the teams with a stick.
I’ve sat there and broken nearly every AWS product in front of account managers so far. At least they listen unlike MSFT ever did.
> We handle the hard stuff so you can focus on the UI.
That sounds very arrogant and diminishing to the UI folks doing the frontend work. Creating a proper UI is hard. Ask your backend engineers to create a good UI and you will see.
There isn't an intermediary api. Aws amplify is a Backend as a Service, and so your components directly query the database instead of you building an api and building the querying logic for the frontend .
Going through the website it all sounds pretty great and for a smaller project that I had to integrate with Amplify I think I would reach for this. The problem I have is that if you're not integrating with Amplify, it's just another UI framework.
Also this thing is heavy, 1.5mb minified and 391k gzipped [1]. Compare that to another heavy UI framework like MUI that is only 477k minified and 131k gzipped [2].
Overall if you're using it with Amplify then that would be a reason to reach for this. But if you are not using Amplify, it just doesn't seem like a good choice.
EDIT:
Ok after thinking about this some more and reading the docs it's actually pretty nice, does a ton of stuff like pagination and login for you. If your boss comes to you needing a hastily done business app and wants you to use AWS. By all means reach for this and Amplify because it will get the app looking 90% good enough for about 5% of the work. The problem with this framework is this is just about the only sound use case. If you're building outside Amplify/AWS, or you are building a more established app, you are going to want to have control over all the things that this framework does for you.
Used Amplify in the past. It’s great for like 80% of basic AWS use cases, but if you’re trying to do something non-standard or even if it’s available in the AWS backend APIs, but just not yet supported by the Amplify components, it can be a huge pain when you have to build that client support yourself separately anyway.
You're more directly connecting your products to a company that has been shown to track what products are doing well so as to create direct competitors.
First thought of what a downside might be, probably others like not able to move platform easily etc.
It’s a security disaster, you have to give developers aws admin in order to use it. At least that’s how it used to be. I stood it up in a separate account for this reason.
I've only glanced at their product page so I could be wrong, but I don't think it would be possible to pull this off without being fairly opinionated about certain things. The authentication component is probably the example that stands out the most. I'm sure it works wonders if your authentication flow matches what they expect, but seems like it would be a pain otherwise.
Biggest drawback for me was having to use VTL to write my resolvers. Normally, I wouldn't mind using a template language for UIs, but not for business logic. This isn't Amplify's fault. They use AppSync, which made the design decision to use VTL. Until AppSync adds support for TypeScript, I wouldn't consider using Amplify toolchain to start a new project.
As an aside, you can still use Lambda resolvers rather than pipeline resolvers, but that's tedious to set up and it's also more costly than pipeline resolvers.
We recently had to move away from Amplify unfortunately.
Here are some examples of problems we faced:
* Building Issues
we consistently have release problems that ends up taking a lot of of our time.
eg: a CLI update would end up breaking our CI [1].
* Overall instability
we regularly have problems that we need to work-around ourselves, sometimes in a really not elegant manner because we have not a lot of control. [2]
* Data Layer
DynamoDB is the DB of choice for Amplify. We do not understand this choice technically. It may make sense from a sales pitch perspective to use a serverless database along with other serverless technologies (API Gateway, AWS Lambda). Technologically speaking though:
- DynamoDB is a great, high performance NoSQL DB. To quote Rick Houlihan: "Not a flexible database but a really efficient DB to use at scale". You need to know your access patterns to query the DB in a efficient way.
- Amplify is aimed to bootstrap an application in no-time, letting front end developers focus on building. When doing so, the product is rarely defined upfront, let alone its access patterns. At this stage, data needs to change shape & format to adapt to new use-cases. In other words, data needs to be migrated. To this date though, the Amplify team does not provide a way to migrate data [3]
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.
There's also other company-specific gTLDs, like .google and .gle for Google, .ovh for OVHCloud, and .george for George, the clothing brand own by Walmart IIRC.
[+] [-] vivegi|3 years ago|reply
I tried it a while ago (more than 1yr ago) and was taken aback by the number of AWS constructs it uses. I wasn't sure what all it was creating on the backend and what the impact of those constructs on the product's recurring billing would be. As-is the cloud abstraction makes it a bit difficult to know (i.e., estimate) what your operating costs are going to be (without using some tools). The Amplify toolset while well-intentioned and already bakes in a lot of AWS guidance/best practice, you feel a loss of fine-grained control over your application's architecture and that was the reason why I did not use it.
It may make sense to use it for certain category of apps where you don't have heavy load (i.e., high opex). The speed of development is certainly helpful for prototyping. But, as others have mentioned, the biggest downside comes from the loss of fine-grained control and when you need to go outside of the Amplify framework to integrate or add stuff, it can become a challenge.
They may have addressed some of these issues in the latest version. I will have to try it out though.
[+] [-] sneak|3 years ago|reply
I frequently wonder if this is by design. When you prototype/launch, these are zero or so close to it that you can ignore them. By the time you have product/market fit and start to scale, you are too busy to replace the expensive and tightly-coupled backend with something more cost-effective.
It's not really a bait and switch, but it's really the worst kind of insidious lock-in.
[+] [-] api|3 years ago|reply
That's a feature. It's designed to herd you into total dependence on AWS cloud.
[+] [-] philsnow|3 years ago|reply
This is common for AWS sales demos. In this case there are cost externalities, but I'm more used to caring about authn/authz externalities, where the flashy demo makes you think "it's so easy" but then you get into the nitty-gritty of making sure that whatever thing is safe to deploy in a production environment.
You have to dive very deep into AWS docs and forum posts (hopefully, but less likely if it's a newer AWS product) to find all the ways to limit access to the thing and especially by the thing, especially since so many AWS demos come with IAM policies that are littered with asterisks.
[+] [-] timclark|3 years ago|reply
Some of the simple things will be easy, everything else will be hard.
Also instead of supplying an SDK, Amplify will provide components that can seriously constrain lots of your UI architecture decisions.
For Javascript the old mobile SDK was much more usable.
Almost all of the AWS services have a sensible JSON API, I wish that AWS would just generate sensible SDK bindings for Swift, Javascript and Dart and stop all development on Amplify.
[+] [-] coredog64|3 years ago|reply
[+] [-] dpedu|3 years ago|reply
The most official doc on the subject seems to be this: https://aws.amazon.com/blogs/mobile/restoring-aws-amplify-pr...
> Note: Following the steps below will restore your Amplify resources such as DynamoDB tables, API’s, Amazon Cognito Userpools, etc.; but not necessarily restore the content within those resources (i.e. database entries, files, users, etc.)
Unbelievable.
Anyway, I happened to be working on my first Amplify-based project just this last couple of weeks so I have some pretty recent experience exploring the various features of this tool. Here's a bit more context:
One thing that is important to understand is that Amplify is split into "hosting" and "studio". I found Amplify Hosting to be pretty well done - you connect a git repo to an "amplify app" and when you push to that repo amplify will build your code and deploy it. I'm using it for static websites, so this means running a few npm commands and whatnot. They handle 100% of the build environment, I don't need to provide a role or docker image or anything. One key feature is that, upon pushing a git branch, amplify hosting will automatically create a new environment with your code deployed within it at a unique URL for the developer to evaluate their changes in.
Adding a "backend" to an environment actually means you get an instance of Amplify Studio. You can see a screenshot of Amplify Studio in the OP and there in the sidebar you can see the list of things a backend provides - Auth, A graphql api, a rest api, functions, and others. Here's where thing's fell off for me - the intended use of Amplify Studio seems to be to click around in the UI or use the CLI. You can create an app and backend via cloudformation or other APIs, but there don't seem to be published APIs to populate how the backend is configured.
Behind the scenes, amplify studio creates a cloudformation stack in your account and, as you click around in the studio UI or use the CLI, creates nested stacks with related resources, like a cognito pool if you turn on auth.
All in all, I think it's a flashy product that looks very attractive to web or app developers. To those that need to consider business continuity, it looks like a nightmare.
[+] [-] eranation|3 years ago|reply
[+] [-] brikil|3 years ago|reply
[+] [-] iasay|3 years ago|reply
I’ve sat there and broken nearly every AWS product in front of account managers so far. At least they listen unlike MSFT ever did.
[+] [-] toinewx|3 years ago|reply
[+] [-] GiorgioG|3 years ago|reply
[+] [-] brunojppb|3 years ago|reply
That sounds very arrogant and diminishing to the UI folks doing the frontend work. Creating a proper UI is hard. Ask your backend engineers to create a good UI and you will see.
[+] [-] jerry69|3 years ago|reply
[+] [-] julianbuse|3 years ago|reply
[+] [-] aaaaaaaaata|3 years ago|reply
Who wouldn't want this?
[+] [-] _fat_santa|3 years ago|reply
Going through the website it all sounds pretty great and for a smaller project that I had to integrate with Amplify I think I would reach for this. The problem I have is that if you're not integrating with Amplify, it's just another UI framework.
Also this thing is heavy, 1.5mb minified and 391k gzipped [1]. Compare that to another heavy UI framework like MUI that is only 477k minified and 131k gzipped [2].
Overall if you're using it with Amplify then that would be a reason to reach for this. But if you are not using Amplify, it just doesn't seem like a good choice.
EDIT:
Ok after thinking about this some more and reading the docs it's actually pretty nice, does a ton of stuff like pagination and login for you. If your boss comes to you needing a hastily done business app and wants you to use AWS. By all means reach for this and Amplify because it will get the app looking 90% good enough for about 5% of the work. The problem with this framework is this is just about the only sound use case. If you're building outside Amplify/AWS, or you are building a more established app, you are going to want to have control over all the things that this framework does for you.
[1]: https://bundlephobia.com/package/@aws-amplify/[email protected]
[2]: https://bundlephobia.com/package/@mui/[email protected]
[+] [-] clarle|3 years ago|reply
[+] [-] bryanrasmussen|3 years ago|reply
First thought of what a downside might be, probably others like not able to move platform easily etc.
[+] [-] pid-1|3 years ago|reply
[+] [-] iostream25|3 years ago|reply
in other words: vendor lock-in... there can be a variety of ways this can screw one over in production...
[+] [-] dijonman2|3 years ago|reply
[+] [-] danielvaughn|3 years ago|reply
[+] [-] picardo|3 years ago|reply
As an aside, you can still use Lambda resolvers rather than pipeline resolvers, but that's tedious to set up and it's also more costly than pipeline resolvers.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] xrmagnum|3 years ago|reply
Here are some examples of problems we faced:
* Building Issues
we consistently have release problems that ends up taking a lot of of our time. eg: a CLI update would end up breaking our CI [1].
* Overall instability
we regularly have problems that we need to work-around ourselves, sometimes in a really not elegant manner because we have not a lot of control. [2]
* Data Layer
DynamoDB is the DB of choice for Amplify. We do not understand this choice technically. It may make sense from a sales pitch perspective to use a serverless database along with other serverless technologies (API Gateway, AWS Lambda). Technologically speaking though:
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
[2] https://github.com/aws-amplify/amplify-category-api/issues/3...
[3] https://github.com/aws-amplify/amplify-cli/issues/1407
[4] https://twitter.com/houlihan_rick/status/1513137762895110147
[+] [-] algo_trader|3 years ago|reply
Is that a live demo? Because the widget doesnt update for me when i change the code
[+] [-] michidk|3 years ago|reply
[+] [-] sacrosanct|3 years ago|reply
[+] [-] memorable|3 years ago|reply
[+] [-] frozencell|3 years ago|reply
[+] [-] mattgreenrocks|3 years ago|reply
If it is even half decent I am very excited about this, lock in and all. Webdev has been a haven of incidental complexity.
[+] [-] happyweasel|3 years ago|reply
[+] [-] frozencell|3 years ago|reply
[+] [-] progx|3 years ago|reply
[+] [-] memorable|3 years ago|reply
[+] [-] clarle|3 years ago|reply
[+] [-] mrichman|3 years ago|reply
[+] [-] 752963e64|3 years ago|reply