Build Go Apps That Scale on AWS

Deploying Database and Lambda Changes



Build Go Apps That Scale on AWS

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

The "Deploying Database and Lambda Changes" 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 runs `cdk diff` to compare the changes with the current environment. The changes show an updated lambda deployment and the addition of DynamoDB. The changes are deployed and tested in Cloud Formation on AWS.


Transcript from the "Deploying Database and Lambda Changes" Lesson

>> So now that we have our Lambda artifacts created and we've defined our infrastructure, we can then go back to those CDK commands. We can do a CDK diff, And take your time, don't rush. I'm just gonna showcase this. If you need to see some code, please, just ask me, I'll go back.

If you run CDK diff, you'll see it's gonna take some time. It's gonna look at that snapshot, which actually exists this time and it's no longer just added green stuff. We're making modifications to our stack, right? If you scroll up, we're adding a new DynamoDB:Table. We're adding a new policy and this is a modification to the existing Lambda Function, right?

And there's some metadata that is changing, right? Basically adding a new service or default policy, which, in layman's terms allows this Lambda communicate with a DynamoDB:Table, right? But this is, I want to highlight kind of the value of doing a CDK diff as like a layer of protection to see, okay?

Is this really what I'm doing my deploying what I wanna do? And then you can just do CDK deploy. Once you deploy items, the first time, it's always the longest time because that's to spin up the brand new resource for it. When you're making updates to the infrastructure, it's a lot faster, okay?

There was a really good question about the local deployment. I definitely think if you are going to have CDK, something you do like 24-7, having a local instance where you can test stuff and kind of move and iterate faster is worth the investment. It's just if I were to set that up for this workshop, it would have been a good portion of it just setting that up.

So we can just wait while this finishes updating and creating. And if all works well, once we query and invoke our Lambda Function, we should see the record in our new DynamoDB :Table. And it should be the username and the password we pass it in. Now let's go back to our Cloudformation and we can just go back here, go to stacks.

If we refresh just in case, we can remove these props, these tabs. Go to our stack, you can see resources, now we'll have a user table. So our lambda function and our user table, we can click into this user table, click into this lambda function. Lambda function, it's really gonna look exactly the same as the previous UI.

Nothing's different, maybe the package size is a little bit increased because we've added more, a lot more files and folders, etc. So obviously that's gonna increase. But if you look at our DynamoDB, if you go to explore table items, you'll see here there's no items it's an empty database, right?

But now we have it deployed. So we have a way to store data which I think is really cool. And now if you go to test and run pretty much the exact same test. Let's go ahead instead of doing one parameter will be two parameters. I'm gonna put username as milky and if you're faster than me just go ahead and insert it right and put password 123, And put password, let's go ahead and test, boom, successfully called.

You know what? I did miss something. My apologies. We didn't actually pipe down the function here. We have the same handler request. So I got too excited. Instead of doing just that handler request cuz it's still calling the same function, we now actually have to make use is our app.

To do my app, okay? We're gonna declare it. And instead of passing the direct function, what we're going to do is my app.API handler that register user handler. And now when we again unfortunately have to go through that same process of creating artifacts, redeploying it but this one will be much faster.

So go back to a lambda directory, you can run a make build and then go back and go right away into a city key deploy. And because our CDK deploy is not deploying new infrastructure, it's not gonna give us that prompt of you want to confirm the change yes or no.

Because we're modifying existing infra and we're not changing the underlying properties of that infrastructure, so we're not gonna get that confirmation message, it's going to deploy it for us. You can see here, there's gonna be an update in progress, right? So now we're updating our lambda function, we're updating everything that's gonna be touched with this new CDK deployment.

Cool, so now we have it, we can go back. I like to do a hard refresh no matter what and if you go back to test if it's on JSON have to put all these parameters in again password One, Two, Three, put our password value here I'm gonna put username and the value instead of value one let's just put Melkey test it.

Boom, no, no error. If we go back to our DynamoDB we hit this with a refresh Melkey password One, Two, Three. So now we have this way to invoke functions and have that invoked function hit other infer that didn't know existed 20, 30 minutes ago. And again, I know we're showing plain text passwords.

You can put the pitchforks down a little bit. We're gonna change this when the hash will make it work in a more production level, starting with hashing and validating that password. But I want to show the step of how we now interact with another piece of

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