Hacker News Reader

Comment by cameroncf | Hacker News Reader

The biggest problem with Amplify is not any of it's underlying technologies. These are all great services. DynamoDB is one of the best things in the entire AWS service portfolio.

The biggest problem with Amplify is that it hides complexity that the developer really needs to have a firm grasp of when designing their application. You really need to think a lot about your access patterns before using DynamoDB. DynamoDB is OLTP and not OLAP. You aren't going to have a ton of ability to do ad-hoc queries with DynamoDB. that's just not a use case it's well suited for.

HOWEVER - AWS Amplify is marketed without that warning - people use it without really understanding that. Then they get stuck when they start trying to treat it like a traditional RDBMS datastore, which it is not.

Amplify "dumbs down" something that really should not be dumbed down. That's it's biggest problem and the reason I also stopped using Amplify some time ago.

View on HN

> You really need to think a lot about your access patterns before using DynamoDB. DynamoDB is OLTP and not OLAP. You aren't going to have a ton of ability to do ad-hoc queries with DynamoDB. that's just not a use case it's well suited for.

This was a trap that I fell into. While I didn't go with Amplify, I went with DynamoDB assuming that "it's a high performance database, surely I'll be able to bend it do what I need it too, right?". I feel like AWS should be more upfront about the limitations of DDB, it's a great database but they sell it like the solution to everything, and it simply isn't.

This is spot on. Parts of Amplify are aimed at people just getting started with Cloud and Programming, which is good and bad. You can shoot yourself in the foot if you drive the car too fast. I think a lot of more advanced people use Amplify services along with the Amplify client SDKs and then do the provisioning using CDK rather than the Amplify CLI.

DynamoDB is a sad hack that heavy marketing had elevated in absence of better offerings on AWS at the time. It's not particularly good as KV store let alone something more serious.

maybe you could argument and suggest as to why it is not good as a KVS which is the number 1 use case for dynamoDB and everything in dynamo was optimized to be a KVS which a lot of multipurpose nosql database can't say.

Because it has arbitrary limits and bad ergonomics. 100 items per transaction wtf. 1MB of data per second write per partition and so on.

> It's not particularly good as KV store let alone something more serious.

Nonsense. DynamoDB is a pretty good KV store, and a killer feature as part of AWS' free tier. I dare you to present a cheaper and more performance KV store.

My experience coding for it on an IoT Hackaton, has made me decide to never touch it again unless there is no other option, like the customer wants it.

Really nothing that could earn my heart over traditional RDMS offerings.

You are comparing apples with chairs and the lack of examples as to why you don't like it doesn't make your comment useful.

Lets start by the way one has to explicitly create indexes, or query types for what one can search for.

No proper REPL experience.

The barebones SDK.

That is how much I can still remember from 2018's experience using it.

So, disclaimer then, that was five years ago

You haven't missed much. The overall developer experience is still... poor.

Dynamo has its use cases. Imagine a database with 100K+ of devices sending different metrics out every minute or so. You need to retrieve metrics by device ID:metric and date/time range. I migrated a similar DB from Cassandra to Dynamo, and it worked really well (for that use case!)

In the years since, I've worked at other companies and seen Dynamo used where it was a really poor fit: tons of filtering/scanning, relatively tiny datasets that require many secondary indexes. I even know of one app that starts up and loads an entire DDB table into memory! If you're not absolutely sure Dynamo is a good fit, it isn't. Use a relational database.

> Lets start by the way one has to explicitly create indexes

I never heard anyone complain that they had to explicitly create primary keys when creating tables in RDBMS.

> or query types for what one can search for.

I never heard anyone complain that they had to put together SQL queries to get data out of a RDBMS.

It seems your only complain boils down to pointing out nosql databases aren't SQL databases, and you didn't bothered to onboard onto the tool you knew nothing about. That's hardly insightful.

With Dynamo, it's not creating indexes that's the problem: I also have to change my code to use those indexes. I've been using DynamoDB off and on, at several different companies over the past 10+ years. I've been using SQL databases for 25+ years. The DDB developer experience is less than optimal.

I'm curious if you can give a long form critique? I've never heard any complaints of it from folks using it "in anger."

I have heard a lot of complaints on it not doing as much. But I swear every time I've taken a dive on those complaints, it has been by folks that don't pay attention to the costs of what they are wanting. :(

DynamoDB is an absolute beast in the right hands. It is just difficult to use and far less forgiving than a basic SQL database - which should have been the go to for something like Amplify.

I would add a bit of my own experience.

Products like this are great. But if you already know the technology, know what is happening and you are using it to basically eliminate a bunch of coding or setup tasks that you would have to do.

The problem this is only great for a certain type of knowledgeable developer who is also setting up the system.

The next person that comes or a junior developer who does not have grasp of the underlying tech will just see a bunch of magic. But he will be required to be productive with it.

So if the original devs leave and don't get people with grasp of the underlying tech, the new people will start accumulating technical debt at an ever faster rate without ever being able to pay it back. Because with so little knowledge and expectation of performance, whenever something small happens that requires you to learn stuff you will skip learning and just move stuff around hoping some random change will fix it.

So I will amend my original statement:

"Products like this are great." But only if you are working on the project alone and don't expect anybody else to join it in the future.

Reply on news.ycombinator.com