A Starter Project and Core Concepts

At Westpoint, we’ve been invested in the Cloud Development Kit (CDK) platform right from the early days when we discovered the potential productivity gains. You will discover more about these potential gains later in the following chapters as we introduce new approaches to cloud solution architecture that this awesome new tool brings.

As a result of our constant curiosity toward CDK and later using it to deliver projects, we have come up with some good practices for organizing CDK-based applications. These practices revolve essentially around code organization and should not be considered complete, by any means, since we are still on this journey ourselves and we add things as we discover them. It works for us, so it might work for you. We would also love to hear of other ways CDK projects can be integrated into other modern workflows. So, if you have such suggestions, please reach out to us via any of our public GitHub repos.

In this...

Technical requirements

Speaking of GitHub repos, you will be able to find our latest CDK starter project by following this link: https://github.com/PacktPublishing/AWS-CDK-in-Practice/tree/main/chapter-2-starter-project-and-core-concepts/cdk-starter/infrastructure.

The Code in Action video for this chapter can be viewed at: https://packt.link/565U3.

The CDK monorepo model

You are probably familiar with the concept of monorepos. The details are outside the scope of this book, but essentially, monorepos point to all code and assets of a certain project, client, or company being in a single GitHub repo as opposed to logically separating the code by, for example, separating the frontend and the backend of the code base into different repositories.

There are many upsides and downsides to using monorepos, and developers use them at varying levels for code organization, from keeping the entire company code within a repo to just storing project-specific code in a single repository. For example, at Westpoint, we like to keep each client’s code in a separate monorepo within a separate GitHub organization. This way, we keep things secure and easier to configure.

But if you have different levels of developer access to different bits of your organization’s code, it’s best to use other methods. We aim to keep things...

CDK concepts

We have initiated our CDK app, but before we go further, there are a few key CDK concepts that you should understand first. Let’s delve into them one by one.

A CDK app

An AWS CDK app is an application written in a programming language, the most popular being TypeScript (see the language flag when we ran cdk init), which uses the standard CDK library alongside custom-written components to define an AWS-powered infrastructure.

Open up bin/infrastructure.ts. You will see the following line of code:

const app = new cdk.App();

The app constantly acts as the root of our CDK application. The reference to the app will be passed down to all our CDK stacks:

new InfrastructureStack(app, 'InfrastructureStack', {})

CDK stacks

Stacks act as high-level containers for constructs, then are used to define AWS services such as ECS, DynamoDB, and others. Looking at our starter repository so far, we will define only one stack – WebStack. It&...

Summary

In this chapter, we introduced a practical CDK starter project you can use when coding CDK. We also learned about some core CDK concepts such as apps, stacks, and constructs. Finally, we created a custom construct and used it in our stack.

In the next chapter, we will take this example further and create a web application that exposes a RESTful API. We will also finally look deeper into the CDK and AWS CloudFormation relationship and how understanding CloudFormation templates will help you when developing CDK applications.