6 ms·

Okay, so what are the downsides? Who wouldn't want this?

bryanrasmussen 4y ago
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.
pid-1 4y ago
Last time I tried Amplify I couldn't get past like their getting started tutorial. That said maybe it got better over the years.
clarle 4y ago
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.
- nkozyra 4y ago
  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.
danielvaughn 4y ago
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.
iostream25 4y ago
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...
picardo 4y ago
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.
- swyx 4y ago
  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
  - picardo 4y ago
    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.
_fat_santa 4y ago
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/ui-react@3.0.4 https://bundlephobia.com/package/@aws-amplify/ui-react@3.0.4 [2]: https://bundlephobia.com/package/@mui/material@5.8.7 https://bundlephobia.com/package/@mui/material@5.8.7
dijonman2 4y ago
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.
- coredog64 4y ago
  You should generally be doing that regardless. Accounts are free and represent the last, best security boundary.
  - dijonman2 4y ago
    Yes, for sure. Limiting blast radius is essential. Just need to build solid automation to make it manageable.

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.

pid-1 4y ago

Last time I tried Amplify I couldn't get past like their getting started tutorial. That said maybe it got better over the years.

clarle 4y ago

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.

nkozyra 4y ago
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.

danielvaughn 4y ago

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.

iostream25 4y ago

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...

picardo 4y ago

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.

swyx 4y ago
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
- picardo 4y ago
  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.

_fat_santa 4y ago

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/ui-react@3.0.4 https://bundlephobia.com/package/@aws-amplify/ui-react@3.0.4 [2]: https://bundlephobia.com/package/@mui/material@5.8.7 https://bundlephobia.com/package/@mui/material@5.8.7

dijonman2 4y ago

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.

coredog64 4y ago
You should generally be doing that regardless. Accounts are free and represent the last, best security boundary.
- dijonman2 4y ago
  Yes, for sure. Limiting blast radius is essential. Just need to build solid automation to make it manageable.