install:
init a project:
to verify it works:
should have no error.
developement:
to watch typescript files changes
see a preview of what you will be deploying:
deploy:
cloudformation stack:
cloud development kit is built on top of cloudformation which is an aws service that allows you to describe a stack in aws using a static file (either yaml or json).
in essence - it's going to convert our code written in typescript, to javascript, which will be then converted to cloudformation and cloudformation will be used to deploy our infrastructure.
sounds complicated, right? luckily cdk abstracts a lot of things away from us, so we get to focus on solving our problems instead of writing yaml by hand.
create a lambda function:
in root folder, create a new folder 'lambda', and create a hello.ts file:
then in the main application file:
let's go to the aws management console, search for cloudformation, click on stacks, and checkout what we've deployed.
under the resources we can see:
aws::iam::role
aws::lambda::function
aws::cdk::metadata
click on the lambda function id to explore it. you'll be able to use the entire code, which starts with <code>use strict</code> and finishes with the sourcemap (because this was code was transpiled from <code>typescript</code>).
further down the page, you'll see tags associated with this function (those were added automatically).
we currently don't have any triggers so click on test and configure test event to test it manually. choose api gateway aws proxy. name the test then click create.
once you click test again the lambda function will be called and you should see the <code>console.log</code> with "hello, egghead friends!" (or your own text).
api gateway:
serverless technologies like aws lambda allow us to build our applications out of small, independent functions that can be called based on events such as an api call.
by default, it's not possible to call a lambda function from the internet - it's safely stored within aws cloud, following the principle of least privilege.
in order to create a rest api to call a lambda function we need to use api gateway. luckily, with aws cdk, we can create a <code>lambdarestapi</code> in 3 lines of code and this is exactly what we're going to learn in this quick lesson!
run:
then import it to the stack file:
now we will use <code>apigateway</code> to create a rest api for our application.
once you've deployed succesfully, the terminal will output a url. click on it to see your <code>lambda</code> function live on the internet.
you can also check your newly created resourced in the <code>aws</code> console. if you click on your <code>lambda</code> function you'll also see that this function now has a trigger (api gateway) associated with it.
environment variable:
environment variables are really useful in programming - they allow us to avoid hardcoding secrets (such as api keys) in our code with added bonus of using different values depending on the environment (hence the name!).
in this quick lesson we're going to learn how to pass environment variables to an aws lambda function deployed with cloud development kit (in a single line of code!)
s3:
trigger a lambda function on file upload:
in the <code>aws</code> console, go to services and search for <code>s3</code>. upload a file to the bucket then check if the <code>lambda</code> function was triggered by going back to services and looking for <code>lambda</code>.
???? you can see your recently accessed <code>aws</code> dashboards in the history sidebar on the left.
in your <code>lambda</code> dashboard notice how a new function was added (for me it was: <code>todoappstack-bucketnotificationshandler050a0587b75-1bq2loud7kpxi</code>).
click on the <code>hellolambda</code> function, then click monitoring and view logs in cloudwatch.
then click on the latest log and expand the <code>event</code> log (it will mention things like <code>eventversion</code>, <code>eventsource</code> etc) and look for the information about your recently uploaded image.
upload a file to s3 automaticlly:
create a custom aws cdk construct:
now that we know a lot about shipping cloud resources with cdk it's time to start creating a serverless backend for our todo application.
we could add the database and new lambda functions to our main stack but after a while it might get difficult to maintain.
instead, in this lesson we're going learn how to create our very own custom cdk construct
learn more about cdk constructs here
create a new file next to our stack file (in the <code>lib</code> directory), called todo-backend.ts:
import <code>aws-cdk/core</code> then, let's type our custom construct (which is going to look a lot like the <code>logobucket</code> code from our stack file).
then import the construct into our main stack app and create an instance of it:
add dynamodb:
import dynamodb to our backend then create a new dynamo db table.
get all items from dynamodb table:
create <code>todohandler.ts</code> (we can also delete the other <code>hello</code> lambda function since we just used it for testing).
we'll have to make some changes to our <code>todo-backend</code> file. let's make a new <code>lambda</code> function:
and create and delete requests:
connect react app to a serverless backend deployed with cdk and fix cors issues
our serverless backend and infrastructure (that we both created and deployed ourselves with cdk!) is ready so we can connect it to our react app.
in this quick lesson we're going to learn how to connect the react app from the source code of this course to our api as well as how to add appropriate cors headers to our api response.
in todohandler.ts:
we need to support options request inside handler as well:
add a custom cloudformation stack output with cdk
once we deploy static assets to an s3 bucket it's good to know, well, where are they exactly - saying that "they're in the cloud" is not a good answer.
we can find the s3 bucket and other resources in aws console manually but there's a better solution - creating custom cloudformation stack outputs that are displayed in the terminal once we deploy.
in this quick lesson we're going to learn how to create a custom cloudformation stack output in order to output the path to an egghead logo in order to add it to our app.
let's fix the missing logo at the bottom of our todo application. we need to tell our frontend application to source it from our <code>s3</code> <code>logobucket</code>.
instead, searching for the logo url in our <code>aws</code> console (not a true hacker move!, we can output the url in our terminal with each deployment.
to do that, let's modify the <code>output</code> in our stack file by adding this:
in stack:
once you deploy, you should see the logo path in the outputs section.
deploy a site with https support behind a cdn with cdk
deploying a static site to s3 works really well unless we consider the fact that you cannot add https support to the site directly in s3. in order to do that - a cloudfront distribution is required.
while it is possible to setup cloudfront with cdk on our own, we don't always have to do anything on our own.
instead, we can use constructs that were created by the community.
in this quick lesson we're going to learn how to use cdk-spa-deploy construct in order to deploy our app to s3 (using <code>createbasicsite</code> construct) and deploy it with https support and behind a cloudfront cdn distribution.
import it to the stack file:
add:
full stack code: