Check out a free preview of the full Build Go Apps That Scale on AWS course

The "CDK Init" Lesson is part of the full, Build Go Apps That Scale on AWS course featured in this preview video. Here's what you'd learn in this lesson:

Melkey discusses how the AWS CDK enables infrastructure as code within a project. The CDK will create and deploy the stack and provide utilities for comparing different states between the current and deployed stack. An initial project is created with the `cdk init` command.


Transcript from the "CDK Init" Lesson

>> Now is gonna be a good time to kinda go into more of the application portion that we're going to write with CDK. Let's go switch over to our coding editor. [COUGH] So here I have like an empty directory. There is quite literally nothing here. But that's gonna change in a quick second.

So what we're going to do is first validate that we have everything installed, so you can do aws -version, right, to make sure you have the correct AWS version or AWS --version. There you go, and we can do CDK --version as well. So those are the versions I'm using.

So if you're gonna map it to yours, you don't need to be on the exact build version, but it may help with what I'm using and certain intricacies there. So with CDK, like I said, it's a framework built by Amazon to build infrastructure as code. And CDK offers us this way to kind of spin up our project.

If you've ever used a Create React app or anything like that, this is gonna be very similar with CDK. So to get started, we're going to do cdk init, and we're gonna do app, and we're gonna do -- language, and we can put go. So before I run this command, CDK was natively created with TypeScript.

The AWS team created CDK and you use TypeScript to use this framework. And fun fact, when I wanted to first create this course, I had CDK with TypeScript involved. But I thought to myself, is that really what I wanna do here? Because it's a Go plus AWS course, not a Go plus Typescript plus AWS course, right?

And so we're gonna use Go to write our CDK. So go ahead and press Enter. You can see that on the left screen there, we've generated a bunch new files. I'm gonna go walk through every single one of these, but this basically allows us to start rolling with our CDK application.

I wanna take a minute to look at this message here. So you can see here applying project template app for go. And it says welcome to you CDK Go project. This is a blank project for CDK development with Go. The cdk.json file tells the CDK toolkit how to execute your app.

So you're gonna check that out. And then some useful commands and these are pretty useful commands, right? The first one is cdk deploy, and this is gonna deploy our stack to our default AWS account/region. And this is an important note here. It's the default, the one you have set up on your .aws credentials files.

That's where it's all going to map, okay? And there's a cdk diff, and this compares the deployed stack with the current state. So CDK has a concept of keeping state of your deployment. And this is super helpful in case you deploy something incorrectly, in case you make a mistake.

Again, like I said, if you're doing a lightweight infrastructure like S3 buckets, not a big deal, not the end of the world, you can tear that down fairly quickly. However, there's instances where you have to be even more cautious than using the UI and typing things. As programmers, like I said, we all make mistakes, and when we create code, we're gonna write something that maybe we didn't intend to write.

So cdk diff is going to allow us to be basically understand the difference of what our preview state is versus what we want to deploy. And then we have cdk Synth, which synthesizes the CloudFormation template. Again, like I said earlier, CDK is communicating with CloudFormation under the hood, and it's creating our code, written in Go, to be consumed and used by cloud formation in the flat file kind of semantics that CloudFormation uses.

And then there's go test, run unit tests, okay? So let's actually jump into the cdk.json file. Now, this is a large file with a bunch of dependencies, a bunch of stuff here. The only thing we really care about is this app line. This is what actually is being executed when we run our command, and this is a go mod download and go run go_cdk.go.

So if you recognize that first portion over here, the go run, when we are running and using go, we were writing go run main.go, right? And essentially it's doing the similar thing here. The file name is go_cdk.go, but it's executing the entry point to this file. And I'm gonna show you this in a bit.

The next part is this go_cdk_test.go file. It's all commented out. We're not gonna be actually using this file. So we're essentially not gonna be testing our infrastructure. We're gonna be relying on CDK deploy to test our infrastructure for us. However, it's worth noting that this is a really good example of how you can test your infrastructure in using tests, right?

You can have an assertion, make sure that it is what you expect it to do. So I do encourage you all to check it out. Personally, testing infrastructure is tough. You really don't know what's gonna happen once you deploy, but there are levels of security you can implement to really validate what you're deploying is what you want to deploy, all right?

And then we will go into the meat and potatoes, which is this go_cdk.go file. And this is really where we're going to be doing a lot of our stuff. And there's a lot of code here. And if you've never seen CDK, it could look pretty overwhelming, especially if we go from our toy Go examples to what we got going on now, it's a little different.

And you can see right away we have some errors, right? Our compiler doesn't know what we're trying to get. So the first thing I would like you to do is, in here, you can run the command go get. When you run go get, it's gonna download all those dependencies for us.

It's gonna download everything that we need to run our code. And you can see here the compiler is like, okay, now I'm Gucci, now I'm fine. So like I said earlier, anytime you get presented with a new file in Go, instead of kind of navigating away yourself, always start with this func main in the package main.

Cuz this is essentially the source of truth of what gets executed. So this is where I'm gonna start. The first thing you may notice is we have this defer function on jsii.Close. Like what is defer, what is jsii? I'm gonna start with explaining what the jsii is, or jsi.

I might be mispronouncing it, but conceptually, it is another framework that AWS built that allows us to use CDK with a language that's not TypeScript, okay? It's basically gonna transpile our code written in Go, .NET, Python, Java, whatever you want to write your CDK code in, to communicate with TypeScript under the hood, all right?

So again, if you use TypeScript natively to write your CDK code, you don't have to worry about this. But if you're going to use another language that's supported, you're going to have to use the jsii framework. And this comes kinda built in when you run the cdk init command that we just ran.

And what this defer does here is defer basically tells our Go code that I want you to run this line of code, this execution after everything else has run. Basically, I want this to be done at the end, okay? Even though it's defined up here, you could have existing processes, things that are running in the background, and you want your defer to execute when those are done, okay?

And the purpose of this, if you kind of dive into this close, it's basically a kernel that's running and it's processing the code that we're writing into TypeScript for us. So when we do this close, we're basically saying, hey, we finished the execution, we've synthesized our application, we've done all the transpiling, we've deployed it to AWS, now you can close the kernel or the client.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now