From: https://github.com/serverless/examples/blob/master/aws-node-rest-api-with-dynamodb/serverless.yml
resources:
Resources:
TodosDynamoDbTable:
Type: 'AWS::DynamoDB::Table'
DeletionPolicy: Retain
Properties:
AttributeDefinitions:
-
AttributeName: id
AttributeType: S
KeySchema:
-
AttributeName: id
KeyType: HASH
ProvisionedThroughput:
ReadCapacityUnits: 1
WriteCapacityUnits: 1
TableName: ${self:provider.environment.DYNAMODB_TABLE}
Isn't DynamoDB supposed to be schemaless? And why is throughput provisioning done here? This config is supposed to be committed, right? What's the idea behind including specific config details?
Why does serverless require you to be very specific with your dynamodb settings?
That's AWS' requirement not serverless'.
The resources section is directly passed by serverless to AWS CloudFormation so it should follow CloudFormation's syntax/rules.
Isn't DynamoDB supposed to be schemaless?
It is. And just like ALL schemaless databases, it needs a key for it to work. Other databases (e.g. MongoDB) just simply create the key for you if you don't provide one. DynamoDB only asks you to explicitly set the key (in exchange for speed and scalability) but the rest of the values are all up to you and it's "schemaless".
Why is throughput provisioning done here? This config is supposed to be committed, right? What's the idea behind including specific config details?
The whole point of using the resources section of the serverless.yml file is to manage your infrastructure through code. By defining the infrastructure that your application/web service needs in code, it makes it so much easier to create, update, or delete those resources.
I don't think anyone would enjoy doing any infrastructure change (e.g. increasing provisioned throughput) to five DynamoDB tables in each of ten different regions manually through the AWS DynamoDB web console. :-)
But unlike other variables, throughput provisioning depends on demand and requirements can change.
When demand and requirements change, you change it in your serverless.yml. Again, the whole purpose of infrastructure-as-code is that you should never have to touch AWS console itself.
How do devs usually enter this into serverless.yml? Also, wouldn't it reset every time it deploys?
It will reset. That's why you have to make the change in serverless.yml, not the AWS console.
If you're referring to different environments with different demands and requirements, you can set set different values for each of them.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With