You will face two different methods to create an Amplify project when you use Amplify. This is just the beginning: it will make a bunch of random-named resources on your AWS account, totally untransparent config files in the local or production environment, and the manual (document) that looks so fancy but is split from AWS’s document system and contains almost zero information. You can barely find the config file sample in their document.
I've used amplify for a thing now, and I wrote a thing to read out the cloud formation they use so I could grab and copy out some of the nice parts while leaving the rest alone and undeployed
It'd be really nice if it was a bunch of CDK constructs you could pull in when you want
I don't know how you actually solve this though, since you don't want to have everything defined across two different languages.
A gql schema defined in CDK maybe would do the trick?
No, I only wrote it in Chinese, as my blog mainly targets Chinese readers. I posted it to HN because I hope the AWS staff can receive the feedback, maybe.
Yeah lol I wasn't confused that the article was in Chinese, I was confused that people were just discussing it casually as though it were plain English. "Is there a translated version of this that I'm missing somewhere?"
But that's just HN, most people comment on the headline without even clicking the link.
The browsers I use either has a button to translate the article (Safari) or did so automatically (Chrome) so I had no trouble reading the article without knowing Mandarin.
Most of our site is built in react, and hosted on ec2. We use Amplify for the forms. It has a pretty nice UI, and automatically generates dynamo tables and graphQL apis for querying and modifying them. It also integrates with Cognito which is nice.
The best feature though is that you can import Figma components directly. I know Figma generates it's own code, but Amplify packages it up nicely so I can import it via cli.
I wouldn't use it for a personal project, but it is great for allowing non-programmers to contribute components. And the automatic updating dynamo tables is worth using the UI for input forms.
Those three are fairly independent, self-contained, and reasonably useful. Unlike Amplify that creates a bunch of stuff in your account that you don’t really control, or Elastic Beanstalk that creates a bunch of stuff in an account that isn’t even yours! Then there was CodeStar…
Yeah, don't use amplify. I once went through the awful experience of less experienced DevOps/devs trying to use it and it was a massive waste. Everything was moved to plain lambda in the end.
Worse even, some parts of Amplify was never published/documented. Reading through just this glue code they were using back then was sufficient to tell that amplify was more of an MVP idea than anything remotely serious.
“Worst” is hard because who has tried all 300 (?) services? Perhaps AppSync is worse, if you step a foot outside the limited use case it was designed for (which is not really documented).
One of the worst blunder of my recent career is not pushing against amplify enough.
I know it is not cool to diss on others' work, but amplify is so wrong on so many level (for my use case) it really is painful.
Want to go off the main road? Sure you can sometimes, but it will break (low code tools are just the wrong abstraction for a dev). Want you to deploy different env in different subaccount? you can but we will make your life miserable. Want to keep your auto generated cognito lambdas on up to date runtimes? can't help you. Want to use custom resources? yeah, however, we will probably mangle your project. Want to add cognito on your front end? Sure, I hope you don't like your app lightway.
Want you use graphql? sure but we will use dynamodb in a way that will make Rick Houlihan cry.
In the end it wasn't the right tool for us, but it sure was attractive for our management. V2 position itself as "code first", so I think they've got the memo. However, I'll still setup a CDK project next time, where you actually can control what happens.
22 comments
[ 5.1 ms ] story [ 44.2 ms ] threadIt'd be really nice if it was a bunch of CDK constructs you could pull in when you want
I don't know how you actually solve this though, since you don't want to have everything defined across two different languages.
A gql schema defined in CDK maybe would do the trick?
https://docs.amplify.aws/gen1/javascript/tools/cli/usage/exp...
I haven't yet but sure I hope it works
But that's just HN, most people comment on the headline without even clicking the link.
https://news.ycombinator.com/reply?id=40541919&goto=item%3Fi...
Most of our site is built in react, and hosted on ec2. We use Amplify for the forms. It has a pretty nice UI, and automatically generates dynamo tables and graphQL apis for querying and modifying them. It also integrates with Cognito which is nice.
The best feature though is that you can import Figma components directly. I know Figma generates it's own code, but Amplify packages it up nicely so I can import it via cli.
I wouldn't use it for a personal project, but it is great for allowing non-programmers to contribute components. And the automatic updating dynamo tables is worth using the UI for input forms.
Also SAM. I run into a new bug or limitation in SAM every other time I touch it. Really need to ditch it for CDK.
Worse even, some parts of Amplify was never published/documented. Reading through just this glue code they were using back then was sufficient to tell that amplify was more of an MVP idea than anything remotely serious.
https://github.com/clushie/aws-amplify-sucks
I've gone down the technical / systems programming path: databases, numerical models, compilers, performance optimization, etc.
The terminology, tech stacks, and development practices for web development seem utterly alien to me.