Amplify UI – Don't just prototype. Connect your UI to the cloud(ui.docs.amplify.aws)
ui.docs.amplify.aws
Amplify UI – Don't just prototype. Connect your UI to the cloud
https://ui.docs.amplify.aws
64 comments
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.
> 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.
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.
[deleted]
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:
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
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]
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
Okay, so what are the downsides?
Who wouldn't want this?
Who wouldn't want this?
raises hand
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]
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]
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.
This is it. There are a lot of training wheels. Things break from version to version. Bugs sometimes take a very long time to be addressed.
It works for getting an app up and running but you'll grow out of it.
For this particular library, I've found a number of documentation issues, but it's what you need for auth if you just amplify.
It works for getting an app up and running but you'll grow out of it.
For this particular library, I've found a number of documentation issues, but it's what you need for auth if you just amplify.
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.
First thought of what a downside might be, probably others like not able to move platform easily etc.
Last time I tried Amplify I couldn't get past like their getting started tutorial. That said maybe it got better over the years.
If you were to wish to switch backend providers, is there some standard API or interface they adhere to?
not yet, right?
will there ever be?
in other words: vendor lock-in... there can be a variety of ways this can screw one over in production...
in other words: vendor lock-in... there can be a variety of ways this can screw one over in production...
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.
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.
youre talking about appsync when the posted article is on amplify UI.. pretty far away from that specific service and ignores a lot of usecases which dont touch appsync
I mentioned that AppSync is a different service but VTL is tightly integrated to Amplify workflow because of AppSync. If you use `amplify-cli` to generate your project, you get a folder full of VTL templates. The only way to modify the default behavior of your Amplify API is to override those templates. So I'd say it's very relevant.
Is this VB for the web?
If it is even half decent I am very excited about this, lock in and all. Webdev has been a haven of incidental complexity.
If it is even half decent I am very excited about this, lock in and all. Webdev has been a haven of incidental complexity.
RAD for the web ;) ? Forget about it.
Rewriting everything (front-end-wise) is a constant source of income for frontend "developers".
It's more like: there's no standard "backend as a service" API, so it's "vendor lock-in city"
Your complaint has been largely addressed by UI component libraries, starting with React and Vue and now Svelte. One can choose IBM's "carbon" library, or the Google "material UI" library and it's numerous derivatives...
If you wish to be snarky about frontend developers not being "real" developers, then I will duly note that you are chiming in on a "backend as a service" promotional thread, and noting that this concept is fine but proposing that frontend developers are the problem, not the notion of Backend-as-a-Service being any issue, producing vendor-lockin. If CRUD is so-well defined, standardize such a market sector service. I agree that much of web-development is CRUD. Much of desktop and mobile GUI development is wiring. Much of programming is instantiating and connecting pre-written code modules. The details matter. No-Code exists, but look where that leaves you in the app development life-cycle...
Your complaint has been largely addressed by UI component libraries, starting with React and Vue and now Svelte. One can choose IBM's "carbon" library, or the Google "material UI" library and it's numerous derivatives...
If you wish to be snarky about frontend developers not being "real" developers, then I will duly note that you are chiming in on a "backend as a service" promotional thread, and noting that this concept is fine but proposing that frontend developers are the problem, not the notion of Backend-as-a-Service being any issue, producing vendor-lockin. If CRUD is so-well defined, standardize such a market sector service. I agree that much of web-development is CRUD. Much of desktop and mobile GUI development is wiring. Much of programming is instantiating and connecting pre-written code modules. The details matter. No-Code exists, but look where that leaves you in the app development life-cycle...
The true reality that precedes your complaint:
The world wide web was created as a remote-folder document-browsing application in which an index-page told you of the contents of a folder, etc. One still speaks of a "web root" folder etc.
It wasn't designed as a FRP state-machine, or as a 2-way-bound GUI.
Before the XML Http Request, there was only loading new resources, so the notion of dynamically updating a page UI was entirely dependent upon clicking something and waiting for a new page to load with the hopeful results of your posted form data or whatever, reflected in the UI, IF the developer was kind enough to have done so.
This situation created the complicated frontend situation of today as it became apparent that the Web would be a general client-server application UI
The world wide web was created as a remote-folder document-browsing application in which an index-page told you of the contents of a folder, etc. One still speaks of a "web root" folder etc.
It wasn't designed as a FRP state-machine, or as a 2-way-bound GUI.
Before the XML Http Request, there was only loading new resources, so the notion of dynamically updating a page UI was entirely dependent upon clicking something and waiting for a new page to load with the hopeful results of your posted form data or whatever, reflected in the UI, IF the developer was kind enough to have done so.
This situation created the complicated frontend situation of today as it became apparent that the Web would be a general client-server application UI
Rabid Application Development
> Take it for a test drive
Is that a live demo? Because the widget doesnt update for me when i change the code
Is that a live demo? Because the widget doesnt update for me when i change the code
For me neither. I don't think its supposed to be a playground. They probably just forgot to disable editing for the code preview.
Looks pretty innovative. The playground looks like the Web version of Swift UI, kinda, visualize while you develop
It’s an innovative way to spend your money on as many AWS resources as possible. And let’s not forget vendor lock-in. Where do I sign up?
Literally every company exists to make money in innovative ways.
is this really what we're complaining about?
is this really what we're complaining about?
I would say there is innovation that increases overall productivity (or pleasure) and there is innovation that merely shifts profits around between companies.
I have no opinion on the degree to which this particular tool falls in each of these categories because I haven't used it.
I have no opinion on the degree to which this particular tool falls in each of these categories because I haven't used it.
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.
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.
What a great customer experience, can't wait to be forced onto AWS by some investor!
Ok no it’s really good when you’re there. Just stay away from new services and make sure the investor is paying the bill. Oh and bag all the certs for when the company goes down the shitter.
[deleted]
What do they mean by connect your UI to the cloud? How is it different than any other component library?
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 .
This sort of thing sounds like "vendor lock-in city", to be blunt, but that is a categorical criticism I level at this entire market niche of BEAAS
[deleted]
(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.
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 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.
> was taken aback by the number of AWS constructs it uses.
That's a feature. It's designed to herd you into total dependence on AWS cloud.
That's a feature. It's designed to herd you into total dependence on AWS cloud.
> 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.
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.
True that. I found it a better bet to use Infra-as-Code and defining everything from the ground up (in the AWS ecosystem, AWS-CDK works well for IaC). It takes some time, but at least we know fully well what constructs are explicitly instantiated and how the dependencies evolve.
Only learning now about the .aws gTLD
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.
Microsoft has some influence on the .ms TLD.
We settled on a .ms domain for a project, and ultimately scraped it in favor of our current name because we couldn’t get Route53 to pick it up.
Initially I thought it was an AWS bug and even reported it to them to no avail. I did some more digging and discovered Microsoft was using .ms for doc sites, and it started to add up. I believe AWS is intentionally not routing traffic to TLDs associated with Microsoft.
We settled on a .ms domain for a project, and ultimately scraped it in favor of our current name because we couldn’t get Route53 to pick it up.
Initially I thought it was an AWS bug and even reported it to them to no avail. I did some more digging and discovered Microsoft was using .ms for doc sites, and it started to add up. I believe AWS is intentionally not routing traffic to TLDs associated with Microsoft.
Google also got .dev, I believe, which ruffled some feathers.
google runs it as a normal domain tho not a brand specific one. like half the ppl on this site have a .dev domain in they bios.
And subsequently Amazon's neo feudalism?
"feudalism is when custom domain" its not that deep smh
who tf decided we gotta have "domains" anyway? like why can't i register laskjdf.ljks3 if i want??! fucking icann gotta get with the times
who tf decided we gotta have "domains" anyway? like why can't i register laskjdf.ljks3 if i want??! fucking icann gotta get with the times
Buy your stuff at the mom and pop store or Walmart, host your apps on Digital Ocean, bam, no longer an Amazon vassal.
Why do they have a Discord?
Cool kids have discord!
This is the real answer.
Devs who have never known a world without node love Discord.
Can't wait for that to end, what a privacy joke they are.
Devs who have never known a world without node love Discord.
Can't wait for that to end, what a privacy joke they are.
Discord is the new Slack, which was the new IRC.
Why not? Almost everybody here knows Discord, some even had an account on it.
Why shouldn't they?
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.
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.
WHat an arrogant slogan :D
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.