💾 Archived View for dioskouroi.xyz › thread › 29427883 captured on 2021-12-04 at 18:04:22. Gemini links have been rewritten to link to archived content
➡️ Next capture (2021-12-05)
-=-=-=-=-=-=-
________________________________________________________________________________
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.
Have things improved?
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?
Is it this thing?
https://docs.amplify.aws/cli-legacy/graphql-transformer/over...
Its everything in the graphql API section:
https://docs.amplify.aws/cli/graphql/overview/
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.
How did you end up in such an unlucky situation?
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.
Can you elaborate?
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?
> to be honest it was an awful experience.
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
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.
Not a whole lot based on our experience few months ago.
May I ask about your (and eunoia's) use case(s)?
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.
That looks interesting; will give it a go in the weekend.
Whoa. Do you have an examples of anything built with it?
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.
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.
Wow, this is the _exact_ experience I had.
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.
We built our authentication around Amplify, but it was so horrible we eventually just rolled our own.
Amplify constantly under delivers. Features are built only enough to make a demo. Now they say they can go from design tool to working app, where dozens of companies have failed over the last 25 years. Call me skeptical.
Low code tools are for making MVPs and prototypes. If something actually takes off you end up rewriting it with a real platform.
My biggest peeve is that these front-end no-code UI tools popping up aren't addressing web accessibility and making matters worst.
I built a SaaS tool (
) to handle the automatic remediation of web accessibility issues currently focused on headless e-commerce platforms. With Shopify being the current offering with plans to address more platforms.
Maybe I should look at offering API's to address the needs of these no-code platforms so they have a way of solving the issues while building.
Where I work, the UXD teams are so deep into their Apple ecosystem bubble they don't even try things out on windows machines, so forget users with special needs they don't give a damn about the significant majority of our users who use windows machines.
I would like Figma themselves to have a go at something like this. Their auto-layout system is close enough to being flexbox that you can actually make decent responsive layout with it. I think a way to export that could be quite useful if done well. Especially for prototypes.
Figma's implementation uses WebGL so it might be difficult to pull off. I think there's some extra resources needed to act like flexbox, compared to actual flex box.
I unfortunately have horrible experience with Amplify as well.
Their official tutorial (something a long the line of "how to run a web app in hour") has several mistakes that cost me a whole day. It is very unprofessional that such an important document was not proofread properly.
In general, I haven't had good experiences with Amplify in the past. A lot of those frustrations are probably better directed at the Cognito and Pinpoint teams specifically.
Amplify's been one of those things that worked amazing for demos and POCs, but was super frustrating to tune for actual production needs. One magical moment for me was the way it would spin up a copy of the entire stack (frontend and backend) for each pull request and tear it down on close, all with basically zero configuration needed. Of course, if you had OAuth or other things that required certain domains and whatnot, it broke, but the promise was there.
However, this past month had a _lot_ of interesting launches from the Amplify org. You can now use Amplify from CDK, override the settings on the resources it generates, and even tie it into a CDK pipeline. There's a streamlined GraphQL transformer so that you can just write a GraphQL schema and get a Rails-like experience that generates a full working app for it, with integrations on DynamoDB and OpenSearch.
https://aws.amazon.com/amplify/blog/?awsf.blog-post-types-fi...
There's a lot to like here. I don't know if any of this would live up to the potential, but at least you can see that AWS is investing pretty heavily in it. I think Amplify has a real future as an alternative universe way of working with AWS for app building. I could see this studio launch being a quick way to prototype/iterate/experiment with designs before giving feedback back to a design team.
After getting burned by the dumpster fire that is Amazon Honeycode, I wouldn't touch this with a 10 foot pole.
Amazon/AWS teams are so distributed and independent that it the quality of the output of one team very rarely reflects in any way on the quality of the output of another.
This is almost always a good thing.
There are of course centralizations and standardizations - the AWS SDK, Console UX, API guarantees, etc.
But Honeycode has almost no relationship to the rest of AWS, technically, or organizationally.
Except what this really means is that nearly any part of AWS you have to deal with has been clobbered together by a series of different teams with little cohesion.
The last time I dealt with AWS and amplify, this was glaringly obvious in several places. Settings pages where one tab looked and behaved radically different from the other. A seeming total lack of communication between teams resulting in badly synced package released with bugs due to version differences. Also frequent omissions in documentation requiring you to hunt it down in github repos or in totally different places(Say Amplify uses X to do something, you might have to find info for using X in an Amplify context in the X docs).
What's wrong with Honeycode ?
1. There is no data export tool. The only way to pull data out is either to copy and paste from each and every table into Excel or Google Sheets and export from there to CSV or to roll your own custom export script using their poorly documented JS API.
2. Once you have more than 3,000 or so rows in a workbook, everything grinds to a crawl. It can literally take over a minute for any kind of data mutation in the administration user interface or in the app interface to be reflected in the display. This means that doing anything on the app becomes literally slower than if you were to do it with paper and pencil. And this is despite paying $20/month for the Plus tier, which purportedly allows 10,000 rows per workbook.
3. The project lacks polish and user-friendliness throughout.
4. It is buggy throughout, and developer updates have introduced new bugs multiple times. For example, recently the last record in a table started getting displayed in my app view even though it is excluded by the list filter in that view.
5. The bug reporting process is difficult to the point that I don't even bother anymore.
6. The first time you try to open an old workbook, it will error out. Presumably they are using serverless and the Lambda function is cold.
This isn't going to work because UI mockups usually have subtle backend/business logic complexities implied by how the UI transitions in a way that can only be addressed with lots of meetings followed by custom code. Most people who try to use this and tools like it will be very pleased until the app doesn't work the way they were expecting. The sinking realization that they are fucked will not be pleasant.
I'd definitely caution people away from Amplify. I use it for small projects -- one offs where I don't particularly care about performance, maintainability, or bundle size. For those sorts of low stakes use cases, it's probably fine.
I'm not sure how much I'm saving over just using the CDK and a lighter weight set of libraries. Maybe nothing.
But for a larger project, it would be an absolutely nightmare to use. Even on my small projects I'm constantly fighting it to play nice with modern JS infrastructure. Want to run Vite + Svelte + Amplify? Get ready for some headaches (or at the very least, tons of compiler warnings and huge bundle sizes.)
The documentation is strongly, strongly geared towards the happy path experience, and if you aren't using React + the blessed service infra, you are going to hit sharp edges and lack of documentation immediately.
At what point is AWS too big? Or should I say, when did they become too big?
It is crazy what they have, they have satellite ground station for example which is kinda neat but yeah... there's an AWS service for that.
They even have 4/5G private cell networks now.
This is a random tangent, I've seen people use 4G LTE networks for video piloted model airplanes, they were able to fly across an ocean between islands ha.
It's 10 miles each way but yeah
https://youtu.be/dxj8JwdQ7Lk?t=1253
They can’t really become too big when they still have two very viable competitors.
when it comes to any kind of development experience. most of the aws products are shit. their core services, lambda, sqs, s3, step function, dynamodb, kinesis coupled with rdms works really well. i don't even know, why do people bother with amplify and all that. just use the core services with cloud formation & sam. if you need some thing more, build out some thing of your own for use case on top of these services and just get on with it.
How do you make responsive designs with this? E.g. cards should stack on mobile but shown in a grid on desktop?
I just use Amplify as a CI/CD pipeline tool for handling distribution, Etc. I don't use the actual framework in my applications.
But does this thing support making the website be entirely written in SVG?!
Does someone know a comparable product from a different company?
(YC S18)
maybe?
This seems to good to be true
Better link:
https://aws.amazon.com/blogs/mobile/aws-amplify-studio-figma...
AWS once again pretending to cozy up to open source when in reality they are shoddily getting their foot in the door with any possible monetization opportunities for it so no one can conceivable do the same. Open source communities should react violently to amazon adopting anything of theirs based on their previous track record.
Awesome!!
Remember, many of these things that get released are usually just vaporware. They may become better 6 months or a year later, or, they may never see the light of day.