(no title)
xrmagnum | 3 years ago
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
[2] https://github.com/aws-amplify/amplify-category-api/issues/3...
[3] https://github.com/aws-amplify/amplify-cli/issues/1407
[4] https://twitter.com/houlihan_rick/status/1513137762895110147
No comments yet.