CDK - Diving deeper into the code

In the last post we setup a simple CDK project that resulted in creation of dynamodb table. Let us analyze the code further.

Starting from where the code begins:

const app = new cdk.App();

From AWS Docs:

A construct which represents an entire CDK app. This construct is normally 
the root of the construct tree. You would normally define an App instance 
in your program's entrypoint, then define constructs where the app is used 
as the parent scope.

Here we are introduced to another CDK term - Construct.

Constructs are the basic building blocks of AWS CDK apps. A construct represents a 
"cloud component" and encapsulates everything AWS CloudFormation needs to create 
the component.
A construct can represent a single resource, such as an Amazon S3 bucket, or it can 
represent a higher-level component consisting of multiple AWS resources. Examples of
such components include a worker queue with its associated compute capacity, a cron job
with monitoring resources and a dashboard, or even an entire app spanning multiple AWS
accounts and regions.

From what I understand the CDK code that we create can be thought of as a graph/tree of Constructs. In this graph we could have an S3Bucket Construct, a DynamoDb table construct etc. These constructs connect to each other in a graph. The root of this graph (or the node with no incoming edges) is the App Construct. Everything moves from there.

The App construct doesn't require any initialization arguments, because it's the only 
construct that can be used as a root for the construct tree.You can now use the App
instance as a scope for defining a single instance of your stack.

All the other constructs that we create require a scope argument:

new Construct(scope: Construct, id: string, options?: ConstructOptions)

In many cases we will be passing in App instance as a scope parameter. The second argument is 'id' - An identifier that must be unique within this scope.

This lets you instantiate and reuse constructs without concern for the constructs and identifiers 
they might contain, and enables composing constructs into higher level abstractions. 

The last parameter 'ConstructOptions' - is an optional set of properties that define the construct's initial configuration. The next line is

new CdkAppStack(app, 'CdkAppStack');

This will create an instance of CdkAppStack

import * as cdk from '@aws-cdk/core';
import * as dd from '@aws-cdk/aws-dynamodb';

export class CdkAppStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // The code that defines your stack goes here
    new dd.Table(this, 'cdkSampleTable', {
      tableName: 'cdkSampleTable',
      billingMode: dd.BillingMode.PROVISIONED,
      partitionKey: { name: 'hashKey', type: dd.AttributeType.STRING },
      readCapacity: 5,
      writeCapacity:5
    });
  }
}

The class extends the cdk.Stack class. The class represents a a single CloudFormation stack. We saw in CloudFormation documents:

When you use CloudFormation, you manage related resources as a single unit called a stack.
You create, update, and delete a collection of resources by creating, updating, and 
deleting stacks. All the resources in a stack are defined by the stack's CloudFormation 
template. Suppose you created a template that includes an Auto Scaling group, Elastic Load 
Balancing load balancer, and an Amazon Relational Database Service (Amazon RDS) database 
instance. To create those resources, you create a stack by submitting the template that you 
created, and CloudFormation provisions all those resources for you.

Our class 'CdkAppStack' represents an Cloudformation stack that we want to create. The stack includes a dynamoDb table. Accordingly we create an instance of Table construct. CDK includes constructs that represent all such AWS resources.

CDK follows the idea of composition. Our code is placed within an App Construct. The App Construct is composed of one or more Stacks (which represent a CloudFormation Stack). The Stack construct is further composed of one or more AWS constructs based on the resources you need to create.

Types of Constructs available:

1. L1 or Low Level Constructs 
1. Provided by CDK.
2. They are resources defined by CloudFormation.
3. All names prefixed by "Cfn" - e.g. "CfnBucket" or "CfnMethod"
4. To use Cfn resources, we must explicitly configure all resource properties, - this means developer requires a complete understanding of underlying AWS CloudFormation resource model.
2. L2 or High Level Constructs
1. Provided by CDK.
2. These can be considered higher level wrappers for L1 Constructs.
3. They provide defaults for several properties and also convenience methods, meaning developer need not worry of being an expert of underlying AWS CloudFormation resource model. 
4. s3.Bucket class represents ab S3Bucket or Method class represents API gateway method.

In our example we used Table which is an L2 construct. the equivalent L1 construct would be CfnTable.

There is also a third type of Construct available - patterns

Patterns are basically a combination of constructs that are designed for common AWS Use cases - aws-lambda-dynamodb pattern provides readymade constructs to setup AWS Lambda function and Amazon DynamoDB table with least-privilege permissions

A comprehensive list can be found here. I plan to test out these in upcoming posts