I use Amplify in a lot of my personal projects because it's backed by mostly serverless components and I can run my personal websites on it essentially for free. While in my job, I often lean for other infra for the services I manage. So I overall agree with the thesis, but I just couldn't get myself to agree with much of the reasoning in this article :/
Parts I liked:
- Callouts of the subscription model are good. I have used Firebase rtdb and firestore quite a bit, and agree it's much easier with those tools to just get an up-to-date view. With amplify, I often avoid subscriptions and just re-call list methods after updates (supported well in Apollo, but still unideal)
- The discussions on Amplify/NoSQL/Dynamo being difficult to pivot match my experience, especially when I was less experienced with NoSQL patterns
> Amplify's approach in using DynamoDB is literally called out as something you should avoid by AWS
Alex DeBrie is a wonderful resource, and I love his books, but I wouldn't go as far as to say that all of AWS calls out using multiple tables. There is lots of active debate on the single-table vs multi-table designs
> the fundamental mistake that's made here is that AWS Amplify puts your data into DynamoDB, which is not a general-purpose database
Citation needed. It's a fairly standard NoSQL database and can be used generally.
> But DynamoDB Scales?
I was a bit confused on this article between the frequent mentions of DynamoDB only being worth it at a large scale ("If you're storing that much plain text data, good for you—maybe DynamoDB can help you!", "But you should only use it when a traditional database won't cut it", etc.) while also claiming more broadly that Amplify will not be useful for large apps because it doesn't scale. It seems to contradict itself there?
I do think this section brings up a great point on the inflexibility of Amplify and trying to pivot a data model, which can absolutely be tricky! But the core message of this section doesn't seem to support the thesis.
> If I was AWS, I would… provide Postgres or similar as a database choice
I use RDS with Aurora/postgres with Amplify by using lambda resolvers and it works well. You can't use VTL, but in my mind that's a feature, as VTL is not my favorite for a few reasons like being hard to test.
In general, this was one of my larger frustrations with this article: it doesn't mention the flexibility of Amplify. Amplify comes with highly opinionated built-ins, but you don't have to use almost any of it, and it's quite easy to plug-and-play other tools if you want. Lambda resolvers are a good example because they're extremely flexible, you can use many different languages/tools/even docker to run your resolvers. But also, I opt to not use Amplify hosting and it's fine. And you can also use your own auth without Cognito if you'd like (especially if you're already using custom resolvers).
It sounds like the author inherited some parts of the codebase in question, so if some of these things were already setup I could see it being time consuming to pivot.
> rethink whether GraphQL is actually fit for purpose: It's just not very good
Again, while I'm not a huge GraphQL fan, this is very much an opinion and a highly debatable one. For many use cases, GraphQL can work well, and I think from a technical perspective it is at minimum arguable that something like GraphQL makes sense for a tool like Amplify where one of its core use cases is multi-platform usage across web/mobile.
Parts I liked:
- Callouts of the subscription model are good. I have used Firebase rtdb and firestore quite a bit, and agree it's much easier with those tools to just get an up-to-date view. With amplify, I often avoid subscriptions and just re-call list methods after updates (supported well in Apollo, but still unideal)
- The discussions on Amplify/NoSQL/Dynamo being difficult to pivot match my experience, especially when I was less experienced with NoSQL patterns
> Amplify's approach in using DynamoDB is literally called out as something you should avoid by AWS
Alex DeBrie is a wonderful resource, and I love his books, but I wouldn't go as far as to say that all of AWS calls out using multiple tables. There is lots of active debate on the single-table vs multi-table designs
> the fundamental mistake that's made here is that AWS Amplify puts your data into DynamoDB, which is not a general-purpose database
Citation needed. It's a fairly standard NoSQL database and can be used generally.
> But DynamoDB Scales?
I was a bit confused on this article between the frequent mentions of DynamoDB only being worth it at a large scale ("If you're storing that much plain text data, good for you—maybe DynamoDB can help you!", "But you should only use it when a traditional database won't cut it", etc.) while also claiming more broadly that Amplify will not be useful for large apps because it doesn't scale. It seems to contradict itself there?
I do think this section brings up a great point on the inflexibility of Amplify and trying to pivot a data model, which can absolutely be tricky! But the core message of this section doesn't seem to support the thesis.
> If I was AWS, I would… provide Postgres or similar as a database choice
I use RDS with Aurora/postgres with Amplify by using lambda resolvers and it works well. You can't use VTL, but in my mind that's a feature, as VTL is not my favorite for a few reasons like being hard to test.
In general, this was one of my larger frustrations with this article: it doesn't mention the flexibility of Amplify. Amplify comes with highly opinionated built-ins, but you don't have to use almost any of it, and it's quite easy to plug-and-play other tools if you want. Lambda resolvers are a good example because they're extremely flexible, you can use many different languages/tools/even docker to run your resolvers. But also, I opt to not use Amplify hosting and it's fine. And you can also use your own auth without Cognito if you'd like (especially if you're already using custom resolvers).
It sounds like the author inherited some parts of the codebase in question, so if some of these things were already setup I could see it being time consuming to pivot.
> rethink whether GraphQL is actually fit for purpose: It's just not very good
Again, while I'm not a huge GraphQL fan, this is very much an opinion and a highly debatable one. For many use cases, GraphQL can work well, and I think from a technical perspective it is at minimum arguable that something like GraphQL makes sense for a tool like Amplify where one of its core use cases is multi-platform usage across web/mobile.