In the previous chapter, we created an API authorizer that does not have any underlying data layer. Now we will create two DynamoDB tables, which are User and Token tables. As per their names, these tables will store our user list and access tokens, respectively.
Now let's add this block to our CloudFormation template's Resources section in order to create our UserTable table:
"UserTable": { "Type": "AWS::DynamoDB::Table", "Properties": { "AttributeDefinitions": [ { "AttributeName": "UserId", "AttributeType": "S" } ], "KeySchema": [ { "AttributeName": "UserId", "KeyType": "HASH" } ], "ProvisionedThroughput": { "ReadCapacityUnits": 1, "WriteCapacityUnits": 1 } } }
If we analyze the definition, we can see that we define the UserId attribute as S, which means string. This might seem surprising and you might ask why we do not use numeric values. Our UserId will be a UUID format (such as 123e4567-e89b-12d3-a456-426655440000) because in DynamoDB, there is no way to create auto-increment values. Therefore, generating random UUIDs in the string format is a better option. In previous chapters, when we created a User object, the Id property was also a string.
You might also ask why we only define the UserId attribute's type?
That's because DynamoDB forces us to define the types of attributes we use in keys. For the User table, we have only one primary key represented by UserId; therefore, we must define its type. We are free to add more attributes to this table, but we are not forced to define them upon table creation. In the KeySchema section, we define UserId as the hash key, so it becomes a unique key for every user.
For the UserTable table, we do not need any secondary indexes, so we skip it for now.
The ProvisionedThroughput property lets us define the purchased throughput value, which we set as 1 for now for both reads and writes. For production applications, you would consider increasing this value according to your needs.