14 ms·

Amplify UI – Don't just prototype. Connect your UI to the cloud

118 points by michidk 4y ago

xrmagnum 4y ago
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: - 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] This disconnection between the initial business cases of DynamoDB and Amplify can even be seen within the AWS teams themselves. [4] We don't believe any of them are to blame. The solo Front End Engineer bootstrapping a quick Amplify app for a PoC feels like a way different use case than a team of highly trained data engineers working on their Single Table Design for their micro-service. Amplify rightfully tries to offer an easy way to deal with storing data. And so it follows a standard SQL design with DynamoDB. This though leads to bad performance (original selling point of DynamoDB) or other limitations hard to anticipate. 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 https://github.com/aws-amplify/amplify-cli/issues/10164 [2] https://github.com/aws-amplify/amplify-category-api/issues/337 https://github.com/aws-amplify/amplify-category-api/issues/3... [3] https://github.com/aws-amplify/amplify-cli/issues/1407 https://github.com/aws-amplify/amplify-cli/issues/1407 [4] https://twitter.com/houlihan_rick/status/1513137762895110147 https://twitter.com/houlihan_rick/status/1513137762895110147
aaaaaaaaata 4y ago
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.
mattgreenrocks 4y ago
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.
- happyweasel 4y ago
  RAD for the web ;) ? Forget about it. Rewriting everything (front-end-wise) is a constant source of income for frontend "developers".
  - iostream25 4y ago
    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...
  - iostream25 4y ago
    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
algo_trader 4y ago
> Take it for a test drive Is that a live demo? Because the widget doesnt update for me when i change the code
- michidk 4y ago
  For me neither. I don't think its supposed to be a playground. They probably just forgot to disable editing for the code preview.
toinewx 4y ago
Looks pretty innovative. The playground looks like the Web version of Swift UI, kinda, visualize while you develop
- GiorgioG 4y ago
  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?
  - onelovetwo 4y ago
    Literally every company exists to make money in innovative ways. is this really what we're complaining about?
    - fauigerzigerk 4y ago
      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.
brikil 4y ago
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.
- iasay 4y ago
  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.
  - deleted 4y ago
    [deleted]
  - aaaaaaaaata 4y ago
    What a great customer experience, can't wait to be forced onto AWS by some investor!
    - iasay 4y ago
      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.
jerry69 4y ago
What do they mean by connect your UI to the cloud? How is it different than any other component library?
- julianbuse 4y ago
  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 .
  - iostream25 4y ago
    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 4y ago
      [deleted]
vivegi 4y ago
(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.
- api 4y ago
  > 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.
- sneak 4y ago
  > 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.
  - blowski 4y ago
    That’s AWS’s pricing model. And SalesForce, Azure, and many of enterprise SaaS offerings.
  - 4y ago
sacrosanct 4y ago
Only learning now about the .aws gTLD
- frozencell 4y ago
  And subsequently Amazon's neo feudalism?
  - arcturus17 4y ago
    Buy your stuff at the mom and pop store or Walmart, host your apps on Digital Ocean, bam, no longer an Amazon vassal.
  - collegeburner 4y ago
    "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
- memorable 4y ago
  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.
  - sneak 4y ago
    Google also got .dev, I believe, which ruffled some feathers.
    - collegeburner 4y ago
      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.
  - hoofhearted 4y ago
    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.
frozencell 4y ago
Why do they have a Discord?
- clarle 4y ago
  Discord is the new Slack, which was the new IRC.
- memorable 4y ago
  Why not? Almost everybody here knows Discord, some even had an account on it.
- mrichman 4y ago
  Why shouldn't they?
- progx 4y ago
  Cool kids have discord!
  - aaaaaaaaata 4y ago
    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.
timclark 4y ago
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.
- coredog64 4y ago
  Promotion-driven development strikes again.
  - mr90210 4y ago
    Nailed it.
752963e64 4y ago
WHat an arrogant slogan :D
deleted 4y ago
[deleted]
dpedu 4y ago
If you're seriously considering using this tool, do a quick google search for "aws amplify backup restore" and read the horrors that follow. The most official doc on the subject seems to be this: https://aws.amazon.com/blogs/mobile/restoring-aws-amplify-project-after-deleting-it-from-the-cloud/ 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.
brunojppb 4y ago
> 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.
eranation 4y ago
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.

118 points by michidk 4y ago

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: - 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] This disconnection between the initial business cases of DynamoDB and Amplify can even be seen within the AWS teams themselves. [4] We don't believe any of them are to blame. The solo Front End Engineer bootstrapping a quick Amplify app for a PoC feels like a way different use case than a team of highly trained data engineers working on their Single Table Design for their micro-service. Amplify rightfully tries to offer an easy way to deal with storing data. And so it follows a standard SQL design with DynamoDB. This though leads to bad performance (original selling point of DynamoDB) or other limitations hard to anticipate. 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 https://github.com/aws-amplify/amplify-cli/issues/10164 [2] https://github.com/aws-amplify/amplify-category-api/issues/337 https://github.com/aws-amplify/amplify-category-api/issues/3... [3] https://github.com/aws-amplify/amplify-cli/issues/1407 https://github.com/aws-amplify/amplify-cli/issues/1407 [4] https://twitter.com/houlihan_rick/status/1513137762895110147 https://twitter.com/houlihan_rick/status/1513137762895110147

aaaaaaaaata 4y ago

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.

mattgreenrocks 4y ago

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.

happyweasel 4y ago
RAD for the web ;) ? Forget about it. Rewriting everything (front-end-wise) is a constant source of income for frontend "developers".
- iostream25 4y ago
  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...
- iostream25 4y ago
  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

algo_trader 4y ago

> Take it for a test drive Is that a live demo? Because the widget doesnt update for me when i change the code

michidk 4y ago
For me neither. I don't think its supposed to be a playground. They probably just forgot to disable editing for the code preview.

toinewx 4y ago

Looks pretty innovative. The playground looks like the Web version of Swift UI, kinda, visualize while you develop

GiorgioG 4y ago
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?
- onelovetwo 4y ago
  Literally every company exists to make money in innovative ways. is this really what we're complaining about?
  - fauigerzigerk 4y ago
    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.

brikil 4y ago

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.

iasay 4y ago
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.
- deleted 4y ago
  [deleted]
- aaaaaaaaata 4y ago
  What a great customer experience, can't wait to be forced onto AWS by some investor!
  - iasay 4y ago
    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.

jerry69 4y ago

What do they mean by connect your UI to the cloud? How is it different than any other component library?

julianbuse 4y ago
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 .
- iostream25 4y ago
  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 4y ago
    [deleted]

vivegi 4y ago

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

api 4y ago
> 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.
sneak 4y ago
> 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.
- blowski 4y ago
  That’s AWS’s pricing model. And SalesForce, Azure, and many of enterprise SaaS offerings.
- 4y ago

sacrosanct 4y ago

Only learning now about the .aws gTLD

frozencell 4y ago
And subsequently Amazon's neo feudalism?
- arcturus17 4y ago
  Buy your stuff at the mom and pop store or Walmart, host your apps on Digital Ocean, bam, no longer an Amazon vassal.
- collegeburner 4y ago
  "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
memorable 4y ago
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.
- sneak 4y ago
  Google also got .dev, I believe, which ruffled some feathers.
  - collegeburner 4y ago
    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.
- hoofhearted 4y ago
  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.

frozencell 4y ago

Why do they have a Discord?

clarle 4y ago
Discord is the new Slack, which was the new IRC.
memorable 4y ago
Why not? Almost everybody here knows Discord, some even had an account on it.
mrichman 4y ago
Why shouldn't they?
progx 4y ago
Cool kids have discord!
- aaaaaaaaata 4y ago
  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.

timclark 4y ago

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.

coredog64 4y ago
Promotion-driven development strikes again.
- mr90210 4y ago
  Nailed it.

752963e64 4y ago

WHat an arrogant slogan :D

deleted 4y ago

[deleted]

dpedu 4y ago

If you're seriously considering using this tool, do a quick google search for "aws amplify backup restore" and read the horrors that follow. The most official doc on the subject seems to be this: https://aws.amazon.com/blogs/mobile/restoring-aws-amplify-project-after-deleting-it-from-the-cloud/ 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.

brunojppb 4y ago

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

eranation 4y ago

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.