FaunaDB vs DynamoDB: Querying capabilities, Pricing, and more

Creating an AWS account

Creating a DynamoDB table, creating, and deleting items using the AWS console

Modeling data in DynamoDB using a Single Table Design (compared to FaunaDB)

Inserting, Updating, and Querying items using the DynamoDB node.js documentclient

Replacing FaunaDB with DynamoDB as the Backend of a GraphQL API with Zero Client Changes

Netlify Functions vs AWS Lambda

WTF is Serverless Framework? Is it the same as serverless? (no, it's not)

Getting Started with Serverless Framework CI/CD and writing your first serverless.yml

Writing an AWS custom authorizer to enable the use of Netlify Identity on AWS Lambda

Converting a Serverless App to run on AWS Lambda and DynamoDB with Serverless Framework

We talk about The differences between a FaunaDB data model and a DynamoDB data model. We go on to explore single table design patterns, keys, access patterns and time to live attributes in Dynamo. We also touch on the adjacency list pattern.

Man 1: [00:00] on the left, we've got our FaunaDB data model. Each to do has an ID, which in this case is generated by Fauna for us, some text which is the text of this to do, whether it's done or not, and who owns it.

[00:11] To translate this data model into a DynamoDB data model we'll take a look at the objects using standard JSON object notation. Our partition key and our sort key are named PK and SK respectively. What we want to be able to do is query for all of the specific users to dos.

[00:29] When querying in DynamoDB we have to match the PK exactly, but the SK is a lot more flexible. We can do things like search for exactly this user ID with an SK of anything that starts with to do, which will return us all of this to dos for a particular user.

[00:45] In this way, we can actually model relational data inside of DynamoDB by taking advantage of the flexible querying nature of the sort key in addition to the exact querying in nature of the partition key. Note that in this case, the PK becomes a user ID and the SK becomes the todo ID, which we generate. We have to generate an ID for the todo, because DynamoDB doesn't do that for us. Luckily, we can use UUIDs before to get a randomized ID. The user ID comes from Netlify identity, so we don't have to worry about that.

[01:16] Then we have the third key, which is sort of a grab bag. We've got when the todo was created, when it was updated and whether it's done or not. Note that the three top level keys are called attributes.

[01:25] The way we create indexes in DynamoDB which allows us to enable different access patterns is by using one of these top level keys. We can't use one of the nested keys as an index key. Notably, if you make an index, you can create what are called sparse indexes which we'll cover later.

[01:42] All of these combines together to ensure that we can query or any users todos. In the same way, we can extend this data model to query for any users settings. For example, one last note about date times, we can set a Time To Live on any DynamoDB object.

[02:00] If we want to set a TTL on a particular object in a DynamoDB table, we have to use the Unix timestamp, which is the number of seconds since 1970. Alternatively, if you're not using the value as a Time To Live value, it will be more human readable if we set the value as an ISO 8601 timestamp.

[02:21] This is what we'll use for created at and updated at since we aren't using them in a Time To Live.

Course

Converting a Serverless App to run on AWS Lambda and DynamoDB with Serverless Framework

Modeling data in DynamoDB using a Single Table Design (compared to FaunaDB)

Share this video with your friends