Build Go Apps That Scale on AWS

CDK Constructs & Stacks



Build Go Apps That Scale on AWS

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

The "CDK Constructs & Stacks" 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 explains the difference between CDK constructs and stacks. A stack contains one or more resources. This application will include a Lambda, DynamoDB, and API Gateway. There can be one or more stacks in an application construct.


Transcript from the "CDK Constructs & Stacks" Lesson

>> And next, we have this app, this AWS CDK new app. And what is an app? What are we even declaring here? CDK has this very interesting concept of constructs, all right? And the way I like to think of CDK is like Lego pieces. You're gonna have bigger Lego pieces.

They can put smaller Lego pieces and even smaller Lego pieces they can put on those smaller ones. So it's like once you define something, you define something else that gets attached to that higher level definition and smaller components that get attached to those. Where I'm going with this is that app acts as our kind of source of truth and the biggest first construct implementation.

That first Lego piece that we will then bind all the other infrastructure to next to where the application came from, where was this infrastructure deployed, where did it come from? And so that's what kind of app does for us. And then we will use app be passed in to the next smaller component, which is a concept called stacks.

And stacks, I'm gonna switch back to the presentation here for just a second. Stacks are basically a collection of individual infrastructure, all right? So you have a stack and that stack can have many different components to it. An example that we're gonna write today, we're gonna have one stack with three pieces of infrastructure.

Three resources defined within that stack, which is AWS Lambda, AWS DynamoDB, and the API Gateway, okay? So we're gonna piece those together to find them to our stack and our stack is gonna bind to our app construct. Again, think Lego pieces, okay, where the lowest level are these individual resources here.

In your application code, you have multiple stacks, multiple resources, up to how you're gonna define them. We're gonna keep it into one stack, and this can allow us to kind of organize our code in a bit more of a constructed way, okay? So you go back, that is exactly what this NewGoCdkStack function does.

So I'm gonna jump into it, even though it's defined right above. So here, we have this function, and it's taking in arguments, it's taking in a scope, which is a type of construct, an ID, and props, properties, which we will then use to help us add different capabilities to our constructs, different parameters.

This could be anything from logging, identity, environment variables, specific things like that, that's where properties comes into play. But what I want you to really pay attention to just right now is the first argument, the scope construct. Because when we call NewGoCdk, we are passing in our app into this first argument, right?

Again, so I'm just emphasizing the point of Lego pieces. App gets passed in stacks, gets attached to app, and stacks then gets attached, or resources then get attached to our stacks. So if we dive a little deeper into this, I'm gonna keep the example, and I hope you all didn't delete the example too, cuz it's a really good one to strengthen this point.

But first, what we're basically doing is constructing our properties, right? If our properties are not nil, we're gonna instantiate our new properties and then we're gonna use those properties to define our stack, right, this line right here. It looks very similar to the app declaration we just saw right here, right?

We have app is instantiated and declared as new app, whereas if we scrolled right above, we have stack which is declared and initialized as NewStack, okay? And this NewStack takes in the scope which is our app id and the reference to those properties, okay? So far, that's okay, cool.

And then this is really the core piece that I wanna double down on. This is an example of resource. This CDK init app gave us an example resource as a queuing system, this awssqs.NewQueue, and this is an individual resource. This is just like the Lambda, the DynamoDB, the API Gateway, which I shared in the previous slide.

So if I just go, I know I'm moving back and forth, so please. But think of the cue that we see in this example as just being one of those inner weight rectangles, okay? And this inner weight rectangle wouldn't be binded to our stack, okay? So if you go back, you can see that if we were to uncommon this, you guys don't have to do this, just kind of follow along.

We have, and let's just, import this just for a second, just we don't get our compiler yelling at us. But we have this queue, and if you notice, this queue is taking in that stack that we just defined, whoops, sorry, Okay, and if we dive deep into this queue, if we just go into it, it's taking in the exact same type signature.

It's taking in this type of constructs.Construct. Okay, so at the end of the day, no matter what level you are, if you're at the app level, stack level, resource level, we're always communicating with this concept of constructs, this concept of Lego pieces, okay? And this resource is gonna be that lowest level that accepts a construct that will then bind to.

All right, and at the end of this function, we return our stack. So we have now binded a resource into a stack, and we've returned it back when we call this NewGoCdkStack function. So we have it here, and now we do app.Synth, because now we know that we're gonna return a stack.

Our app can synthesize that we have passed down the app construct to a stack and we are then going to compile and create what we need for AWS to read, hey, I need the following resources defined inside of our stack. Initializing this, do you have to manage ports and things like this or is that it's all abstracted away?

You don't even have to manage any ports. Nothing's gonna be binding on your port here, on your computer to the cloud. And the port management between resources is done via CDK. There's some resources that you do have to do some port manipulation. But for the most case, CDK does abstract it for you and it kinda used the content of more config and stuff, but that's still something that you'd pass into the properties.

Of okay, I wanna actually run on this port or to something that's specific to my needs that you can control with the props. Okay, and one last portion here. So this props isn't necessarily empty, we're passing in this Env value. And Env value is this env function. If you go down, it's this really big piece of commented out code, but if you really look at it, it's just returning nil.

Now, the reason why it's returning nil is because it's using the default AWS account and region that you set up when you run AWS configure. When you map your CDK, it knows all of that kind of innately and use the default properties. But for whatever reason, let's say you want to deploy this stack to a different account or a different region, this example shows exactly how you can do that with the Following.

You can just return an AWS CDK environment and specify directly the account and the region or any other kinda property you want, okay? So for our case, we're gonna keep it as default just to kind of extract some further kind of nuance. But that's something I do wanna point out that that is how you can control the development and the deployment of your application.

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