DynamoDB

Databases are a core component of any real-world application and yet, up until now, we’ve been ignoring them. There are reasons for this. Databases complicate our efforts while we want to focus on learning FP. We should keep databases out of the core part of our application, at the edges where they can’t contaminate other parts of our code. However, a practical guide would be incomplete without integrating a database in at least one application. So, we’ll add DynamoDB.

What’s DynamoDB?

DynamoDB is an AWS-managed service, meaning that there are no servers or anything for us to maintain. The only thing we specify is how much read and write capacity we want our database to have. In fact, even that’s no longer required. DynamoDB can automatically scale capacity depending on traffic (so-called on-demand provisioning). We do pay a bit more for this convenience, so if our traffic is predictable, setting capacity ourselves is still the better option.

What kind of database is DynamoDB?

DynamoDB is a NoSQL database of the key-value type, with some qualities of a document database mixed in. We specify an item by picking a single or composite key and adding any other attributes we desire. Those attributes can vary from item to item, or evolve with time. This is schema-on-read. That is, we decide what’s in there when we retrieve the data (SQL databases on the contrary are generally schema-on-write, meaning that we determine beforehand what a row can contain). Because we generally retrieve an item based on a key and writing is split over a large number of partitions, such operations are very fast, taking only milliseconds, even at a large scale. Our query options are limited to the keys as well as a limited number of optional indexes, defined by AWS as “local secondary indexes or global secondary indexes.”