I was working heavily with amplify a couple years ago and to be honest it was an awful experience.
Common use cases weren’t handled well, deployment failures were common, overall architecture was actually less coherent when using amplify than just the constituent AWS services directly, etc…
It felt like a kitchen sink of functionality that no one was incentivized to actually make work well together.
My team (5 engineers, 18 months building so far) currently runs the largest amplify based project in terms of number of resources used. We have a direct connection to the core team and their support has been great. Things were quite rough until about 6 month ago. The new releases in version 7.5.x unwind a ton of technical debt that caused serious instability. If I were to start our project over again knowing what I know now I might use SAM or the serverless framework instead of amplify, but I am not sure. The graphQL spec definition to dynamo table feature is the entirety of the magic in amplify IMO, and it has seriously sped up our development time. I strongly recommend against using any of the UI components, or many of the features that appear to be "tacked on the side" because in my experience they are tacked on and don't work well. Happy to answer any questions.
> The graphQL spec definition to dynamo table feature is the entirety of the magic in amplify IMO
Can you point me to the "good stuff" in their docs? A brief Google search quest revealed several things that all seemed to be GraphQL to CloudFormation/Dynamo/.. Which one do you use and trust?
you create a graphql API spec and amplify builds all of the appsync resolvers and dynamo tables for you. Pretty good support for different auth methods and table schemas.
Looking at the newest version of the docs it seems they are indeed deprecating some of the weird niche features and doubling down on the things that already work well.
Nope. I made the mistake of architecting my current project around Amplify. Deployment errors are thankfully rare these days, but things that should be easy are hard, and there are many seemingly obvious use cases that the Amplify CLI doesn't handle.
The worst is when you have to onboard a new developer. No matter what it won't deploy and just hangs and you have to start new. You have to include that .amplify directory and set up everyone on aws version control.
Netlify and Vercel read directly from your repo. I left them because they did not have pg npm and build failed. I also had to open up the database to the public.
I've found if there was an easier way to do it, the original software would be written to do it that way, and the fundamental unavoidable unit commodity will always be a server you ssh into it.
I wonder how fast 1,000 components render? And if effectful components that call network requests create race conditions?
Not only were all the issues you mentioned common, but the quality of their libraries(JS in my case) were just horrendous. At one point there was a run time crash in their blob storage library whenever you listed an empty bucket. I tracked the root cause down to one of their devs intentionally casting away type information(`as any` in typescript) and thus not realizing there were more cases than they were handling. This somehow passed code review and testing and was published.
It was absolutely horrendous. We barely moved a millimeter because we were constantly slowed down by their tooling. I wrote a very long issue about this and just got some community representative who assured me who would do <a series of vague, non-committal promises>.
Shortly thereafter we changed to GCP and Firebase and we were at feature parity in no time and moving fast after that.
I had bad experiences with both Amplify and Figma. Figma banned my account because they didn't like the email domain. I sent all the info they asked for to reinstate it and they stopped replying without unbanning the account. I definitely wouldn't base the core of a project on either service.
I find AWS Amplify is good for smallish projects, things like blogs, portfolio websites, basic ecommerce sites etc. The config is super easy. 1 click integration with github, protect autodetection (e.g nextjs) and CI/CD pipelines are ready to go.
I recommend it, especially if you just wanna knock out a project without wasting time with ops
Coincidentally, 2 hours ago I submitted Molecule.dev right here to HN (an hour before this AWS submission), a full-stack solution which aims to address all of the time consuming pain points of building (common functionality), maintaining, and releasing cross-platform apps.
It isn't a UI builder like AWS Amplify Studio, but I think we can do it better. We cover all of the most common use cases and are planning on adding more, all without any vendor lock-in or unnecessary convoluted abstractions.
Next to our FAQ section (or beneath it if you're on mobile), there are links to a demo app for every platform so you can try out all the functionality currently available. We'll be adding new options every week, depending on the input we get.
We'll also soon be rereleasing an email app using the Ionic option.
It bothers me immensely that they redirect docs for services that work perfectly fine by themselves to amplify docs with a note that says something like "use amplify".
Other than that, using AWS services directly is always a much better experience. In my opinion amplify is like a dumbed down version of that.
I (at my workplace) use Amplify only for the SPA frontend which is a typical React app. Setting it up was bit of a challenge due to CORS issues, not something to do with Amplify as such. I like the nifty PR feature where it automatically creates an end point to test a patch. I've also setup auto-deploy on the master branch.
So far no challenges.
IMO if we don't use too many features of Amplify and use it as a pure frontend build + deploy + host then we could extract good value out of it. An alternative is Cloudfront + S3 in which case you need to maintain a deploy script.
I'm fairly confident Amplify is in fact a wrapper over Route 53, Cloudfront and S3 plus a few lambda functions to take care of build+deploy.
The TypeScript types, the prebuilt components, and the code generated by the CLI are total garbage.
It feels like the whole project is written by a junior.
Every time it’s been faster to use Amazon-cognito-identity-js and roll my own forms instead of bashing my head against the wall trying to customise their weird needless shadow DOM implementation.
Common use cases weren’t handled well, deployment failures were common, overall architecture was actually less coherent when using amplify than just the constituent AWS services directly, etc…
It felt like a kitchen sink of functionality that no one was incentivized to actually make work well together.
Have things improved?