Amazon Web Services (AWS) is a powerful expansive cloud infrastructure platform for building modern web applications.

AWS provides services for data, presentation, authentication, security, video encoding, and much more. Offering over 175 fully-featured services from data centers globally, AWS powers a large percentage of the internet.

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

graphql

**Build a fully managed, serverless GraphQL API powered by TypeScript and AWS CDK in a matter of hours, not days.**

AWS CDK gives us the power to go all-in with infrastructure as code for AWS. With it, we can create a full GraphQL API with AppSync, a database with DynamoDB, serverless functions with Lambda, and much more. 

In this course, you will learn how to do all of the above from your command line and code editor, which will save you time and give you greater flexibility. 

Want to delete your stack? That's fine, just run `cdk destroy` and *poof,* all of the resources are gone. Changed your mind? Just deploy the stack again and they all come back. 

**AWS CDK makes it that easy.**

And since we are working from the command line and our code editor, we will take advantage of TypeScript and other third-party libraries to improve our developer experience. 

So stop wasting time in the AWS console, check out this course, and learn how to leverage infrastructure as code to your advantage.

Kamil Khadeyev

You can create an AWS CDK project entirely on the command. In this lesson, you will learn how to install the AWS CLI to view all of you existing S3 bucks and to initialize a CDK app with TypeScript. 

You can find the CLI documentation here at [Configuring the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)

Create an AWS CDK Stack From the Command Line

Time to deploy! Learn how to use the `npm run watch` command to watch for changes and compile TypeScript to JavaScript. 

But, the main thing you'll learn is how to use the `cdk deploy` command to deploy your app to AWS and then navigate to your app through the AWS web console.

Deploy a CDK stack to AWS

There are only a few steps you have to take to create a live GraphQL API with AWS CDK's AppSync package. 

First, define a GraphQL schema. This is where you define the data you want to query and create query and mutation functions. 

Then, AppSync is used to create a new GraphQL API, passing in the schema you just created. When you deploy, an API key will be generated. You will need this key to interact with the API.

Create an AWS CDK AppSync GraphQL API

The default key that is generated for your AppSync API expires in only 7 days. It would be a big pain in the fingers to update your app every 7 days! 

Instead, you can use AppSync to create and configure your own API key, where you can set whatever expiration date you want.

Create an API Key with AWS CDK AppSync

Without data, you can't query for data 🤔

You can add data source resolvers to your GraphQL API in the AWS console, but in this lesson, we'll be doing it all in our CDK app. This is in adherence with the infrastructure as code best practice.

We'll create a lambda function entirely within our CDK app. We'll create a data source with our AppSync GraphQL API and add our lambda function as the handler. Then we have to make sure that data-source is invoked when there is a query to `listBooks`

Connect an AWS Lambda Data Source to an AppSync GraphQL API

Having a hardcoded source of data isn't going to work out in the short or long term. We need something a little more dynamic. 

That's why we'll be learning how to create a **DynamoDB table** to store our data instead! In this lesson, we will create a table in our CDK app, and grant our lambda function read access to the table.

Create a DynamoDB Table in an AWS CDK App 

Now we have to set up our Lambda function to actually read data from our DynamoDB table. 

The hard coded data in our handler function is getting deleted and being replaced with code that scans our table and returns its contents. 

To make this happen we'll be using `aws-sdk` to get access to `DynamoDB.DocumentClient` which gives us a simple API for interacting with our tables.

Read Data From a DynamoDB Table In an AWS Lambda Resolver

It would quickly get out of hand if we had to create TypeScript types for every type in our GraphQL schema. Luckily there are a couple packages from `graphql-codegen` that we can use to make our lives easier.

We'll create a `codegen.yml` file where we'll specify our GraphQL schema and choose the location of the types file we want to generate based on the schema. 

Then we can create a script in our package.json that runs the codegen.

For more on using TypeScript with AppSync Lambda Resolvers, check out Benoît Bouré blog post: [How to use TypeScript with AppSync Lambda Resolvers](https://benoitboure.com/how-to-use-typescript-with-appsync-lambda-resolvers)

Generate TypeScript Types From a GraphQL Schema

Right now our database is read-only. Let's fix that! 

In GraphQL you make changes to your database using what are called *mutations*. We can define a mutation in our schema and then create a new lambda function that handles writing to our DynamoDB table.

Perform a GraphQL Mutation with an AWS Lambda Function

You may notice that sometimes when you make a query or mutation after not using your app for a while, it will be extra slow. What gives? 

There are a couple of things happening. First, a lambda function goes through a "cold-start" after being run for the first time in a while. AWS is downloading the code and spinning up an environment. 

Second, if you are using the default settings, your function doesn't have much memory to work with. You can specify the amount of memory your function has available in its configuration.

Reduce the Latency of Your AWS Lambda Functions 

As of now, we can only create a single book or query for ALL of the books. Let's create a query that searches for a book by its ID. 

It is very similar to querying for all of the books. You can copy over the code for the list books Lambda and then create a new handler function. 

The function deviates since you need to search for a book by its ID. You will use the DynamoDB DocumentClient method, `.put` instead of `.list` . And you will pass that function an ID.

Query for AWS DynamoDB Items by ID With an AppSync GraphQL API

We are repeating the same pattern across all of our lambda functions. We can extract the common parts into their own constant to save ourselves some time. 

By generalizing the repeated code we have now made our app easier to refactor. Let's take advantage of that by refactoring our Lambda functions to use the Arm/Graviton2 architecture which enhances cost performance by 20%. 

All you have to do is add an `architecture` prop to your lambda config with a value of `lambda.Architecture.ARM_64`

Refactor AWS Lambda Functions to Use Arm/Graviton2 Architecture in CDK

What do we do when one of our GraphQL query functions is running slow? Where do we start figuring out the problem? 

Enabling all logs with AppSync and setting up X-Ray gives you a powerful bug hunting combination. You can use the logs to find your request logs and a trace ID that you can use with X-Ray to see a graph of your requests. 

From there you can see exactly which request is having issues and investigate it further!

Use AppSync Logging and AWS X-Ray to Debug Performance Issues

Continuing with building our GraphQL CRUD API, we now need a way to update an item. We'll do this by using a mutation. 

DocumentClient update expressions are cumbersome, instead of writing them ourselves, we are going to install the **[dynoexpr](https://github.com/tuplo/dynoexpr)** library that will generate them for us. 

But, in order to be able to bundle the third-party package into our lambda function, we will use the **[Amazon Lambda Node.js Library](https://docs.aws.amazon.com/cdk/api/latest/docs/aws-lambda-nodejs-readme.html)**

Update an AWS DynamoDB Item Using a Third-Party Library In a Lambda Function

AppSync supports GraphQL subscriptions out of the box! We don't even have to write custom code. 

All we have to do is create a Subscription type in our GraphQL schema with `@aws_subscribe()`, and pass that the mutation we want to subscribe to.

Add a GraphQL Subscription to an AWS AppSync API

There is a slight chance that your book startup didn't work out. Or maybe you created your CDK project just as a learning exercise. Either way, it's best to clean up after yourself in order to not get hit with any surprise charges. 

You can easily destroy your stack and its resources from the command line with `cdk destroy`. But don't worry. You can easily restore your stack with `cdk deploy`. This is the power of infrastructure as code!

Delete and Restore an AWS CDK Stack 

A boat tour on a river of knowledge, linearly guiding you through the core of AWS. 

Cloud Infrastructure Fundamentals with AWS

Through exploration and comparison, you'll come away with actionable knowledge for designing and extending schemas.

Designing GraphQL Schemas

Go from "I have no idea what a lambda function is" to "I know quite a bit about AWS Lambda, and I'm going to use it to solve my problems" by taking this course.

Learn AWS Lambda from scratch

Build a GraphQL API with AWS CDK and AppSync

https://app.egghead.io/api/v1/lessons/aws-create-an-aws-cdk-stack-from-the-command-line/subtitles

Tomasz Łakomy: [0:00] Before we start, let's make sure that we have the newest version of CDK installed. In order to do that, I'm going to run npm install aws-cdk. To make sure that CDK was successfully installed, I'm going to run cdk --version. Nice.

[0:15] Another thing that we need to do is to make sure that our AWS command line interface has been configured properly. If you don't know how to do this, I recommend checking out this page from AWS documentation. A link to that is in the description to this video. For instance, I can run aws s3 ls, in order to list all S3 buckets in my account, including half-life-3-source-code.

[0:37] Now, with everything prepared, I can go ahead, clear all of that, and create a folder for our project. This project is going to be a bookstore app. I'm going to call it book-store-graphql-api. If I go to this directory, now I can run cdk init app --language, and we're going to choose typescript for this project.

[0:58] This is going to take a second and boot start our entire CDK project for us. Nice. All done. Let me go ahead and open up my Visual Studio Code editor, and we can see all the files that CDK has generated for us. For instance, if you go to lib directory, here we can see our empty stack.

https://app.egghead.io/api/v1/lessons/aws-create-an-aws-cdk-stack-from-the-command-line/transcript

https://app.egghead.io/api/v1/lessons/aws-deploy-a-cdk-stack-to-aws/subtitles

Tomasz Łakomy: [0:00] Let's make sure that we can deploy this empty CDK stack. In order to do that, let us open up the terminal and run npm run watch. This is going to enable TypeScript configuration from TypeScript to JavaScript in watch mode.

[0:13] For instance, if I add this variable, which is a TypeScript variable, because it is of type string, I can see that a JavaScript file was created for me. You can see that it was successfully compiled because there are no types here. With that, I can open up a new terminal tab. Let me remove this bit in the meantime. I'm going to run cdk deploy, in order to deploy this empty stack to AWS.

[0:36] After a couple of seconds, we can see that our stack has been successfully deployed. Let me navigate to AWS Management Console. Next, I'm going to navigate to CloudFormation, in order to make sure that our stack is successfully deployed to CloudFormation. We can see two stacks here. This is the internal CDK one, and this is our stack that we're going to build over the course of this course.

[0:59] If I click over here, I'm going to navigate to Resources, and we can see that our stack has been successfully created. Even though there isn't much here, apart from this AWS CDKMetadata, but this is going to change very soon.

[1:11] Last side note, if you cannot see you're stack over here, make sure that you have selected the proper region in AWS Console.

https://app.egghead.io/api/v1/lessons/aws-deploy-a-cdk-stack-to-aws/transcript

https://app.egghead.io/api/v1/lessons/graphql-create-an-aws-cdk-appsync-graphql-api/subtitles

Tomasz Łakomy: [0:00] Every GraphQL API project starts with a schema. In order to create a schema, let me create a folder called GraphQL. Inside of it, I'm going to create a file called schema.graphql. To create a schema for our bookstore app, let's start with a type for a book. Each book is going to have an ID, which is going to be of type, ID. Each book is going to have a title, which is of type, string.

[0:22] Next, we're going to be able to mark whether we have completed a book or not. This is going to be a Boolean. We're going to also have a rating, which is of type, int. We're going to also have reviews, and reviews are going to be an array of strings.

[0:36] Note, that each book has to have an ID and a title, but the flag specifying whether we have completed the book, its rating, and its reviews, are completely optional. Apart from developer-specified types, GraphQL also has support for special types, including queries and mutations. In GraphQL, queries allows us to query the data, and mutation -- you've guessed it -- allows us to mutate the data.

[1:01] As such, I'm going to add a type Query. Inside of it, I'm going to specify a listBooks query. This is going to return an array of Books. Note that there are no exclamation marks here because we can have an empty list of books. Then, this query, the listBooks query, would simply return a null.

[1:19] For now, let's leave the schema and go back to our stack. First of all, in order to create an AppSync API, we have to install the AppSync construct for CDK. I'm going to open up my terminal and run npm install @aws-cdk/aws-appsync. Next, let's import it. I'm going to import everything as appsync from "@aws-cdk/aws-appsync".

[1:40] In order to create an AppSync API, I'm going to create a variable called API. I'm going to assign it to new appsync.GraphqlAPI. Every CDK construct takes three arguments. The first one is the scope which is usually this. Second one is the ID. I'm going to just call it "MyAPI". The third one are the props.

[1:59] In that case, the only thing that the AppSync API requires is the name. I'm going to call it "My Book API". I'm going to also assign it a GraphQL schema. This is going to be a GraphQL schema appsync.Schema. I'm going to take it fromAsset("graphql/schema.graphql").

[2:18] This is enough in order to create an AppSync API which is powered by this GraphQL schema that we have just created. Before we deploy the stack, let us run cdk diff to understand what exactly are we about to deploy.

[2:31] This stack is going to deploy three things. It's going to deploy our GraphQL API. It's also going to deploy an instance of an AppSync GraphQL schema. Also, it's going to assign a default API key so that we are able to call this API.

[2:45] With that, let me clear the terminal and run CDK deploy in order to deploy all of that into AWS. The deployment was successful. Let me go back to CloudFormation console and click on the Resources tab again. We can see that all of three resources that were listed by cdk diff command have been successfully deployed.

[3:05] Right now, I can go to AppSync console to see this API that we have just created. We can see this API over here. I'm going to click on this title to navigate through it and click on the Schema. Here, we can see the schema that we have created in our project that has been successfully deployed to AWS.

[3:23] The best part of building an API is being able to call it. To do that, click on Settings in order to copy the path to our API. We can see that over here. Next up, I'm going to navigate to GraphQL Playground. Honestly, any GraphQL client is good for that. I just happen to use GraphQL Playground.

[3:42] I'm going to paste this endpoint over here and click on OPEN. Whoops. We have a problem. I'm seeing a 401 error, which means that I don't have access to this API. That is by design. In order to use a AppSynch API, by default, we have to specify an API key. We can see that a default API key was created for us by CDK.

[4:04] I can just copy that over here, go back to my client. I'm going to specify an HTTP header. Let me zoom in a bit. I'm going to create a "x-api-key". I'm going to paste the API key for our API. This is better. I can click on the Schema tab now in order to see the GraphQL schema of our API so we can see the type Book over here.

[4:25] Let me test that. I'm going to do a query of listBooks. Inside of it, I'm going to call listBooks. I'm going to try to get the ID and a title of a book. When I hit Play, we can see that the API works fine, but I am not getting any books, which makes sense because we don't have any books yet.

https://app.egghead.io/api/v1/lessons/graphql-create-an-aws-cdk-appsync-graphql-api/transcript

https://app.egghead.io/api/v1/lessons/graphql-create-an-api-key-with-aws-cdk-appsync/subtitles

Tomasz Łakomy: [0:00] When we deployed our AppSync API, a default API key was created for us. You can see over here, that it's going to expire seven days after creation, which is not exactly optimal. Imagine that you would like to use this API key in a mobile app. You probably don't want to update this key every seven days. As such, we're going to create our very own API key to use in this API.

[0:22] In order to do that, we're going to use the AuthorizationConfig prop from AWS CDK AppSync construct. I'm going to specify a default authorization, which is going to be of type, AuthorizationType. I'm going to use the AppSync AuthorizationType.

[0:35] There's a number of authorization types which are supported by AppSync. You can use the API key, you can use the identity and access management from AWS, you can use your very own Lambda authorizer, and, for instance, also a Cognito user pool.

[0:52] In this example, I'm going to keep on using the API key. As such, I'm going to specify an API key config. I'm going to name this API key as my-very-own-api-key. I'm going to set an expiry date. This key expires after CDK expiration. I would like this key to expire after a year. I'm going to do, after cdk.Duration.days(365).

[1:17] As a reminder, the default API key which is created by AppSync, lasts up to seven days. This key is going to last for 365 days, which is of course, a whole year. Next, let's deploy this update. To do that, I'm going to open a terminal and run, cdk deploy.

[1:34] After a successful deployment, we can go back to AWS Console to the Settings tab in our AppSync API. If we scroll down a bit, we're going to see that this particular key expires in the year of 2022, which at the time of this recording, is next year.

[1:48] Let's verify if this API key still works. In order to do that, let us copy this API key. I'm going to navigate back to the GraphQL Playground. I'm going to paste this API key over here and hit Play again. We're going to see that it works fine, and I'm able to fetch the data from the API.

https://app.egghead.io/api/v1/lessons/graphql-create-an-api-key-with-aws-cdk-appsync/transcript

https://app.egghead.io/api/v1/lessons/graphql-connect-an-aws-lambda-data-source-to-an-appsync-graphql-api/subtitles

Tomasz Łakomy: [0:00] Our API is still far from perfect, because I'm not able to access any data. In order to actually fetch data whenever we try to list all the books, we need to add a data source.

[0:10] Let's navigate back to the AWS Console. If you go back to our API and on the schema page, we're going to see, on the right-hand side, that there is a list of resolvers. Right now, there are no resolvers attached to anything in this API.

[0:24] For instance, we have this query of listBooks. We can try to attach a resolver to it. We can see that there are currently no data sources for this particular query. That is why we are always getting a null over here. I could just click over here and add a data source.

[0:41] There's a number of possible data sources that are supported by AppSync. For instance, we could fetch the data from my DynamoDB table, AWS Lambda function, or any HTTP endpoint on the web. In this course, we're going to play with AWS Lambda resolvers. We are not going to use the AWS Console in order to do that. Instead, we're going to stay in the CDK Land. The reason for that is that we would like to be consistent and always follow the best practices of using infrastructure as code, as opposed to clicking in the AWS Console.

[1:12] In order to use a Lambda resolver, first, we need to be able to create a Lambda function. To do that, open up the terminal. Run npm install @aws-cdk/aws-lambda in order to install the AWS Lambda construct. Next, let us import it. I'm going to import everything as lambda from "@aws-cdk/aws-lambda".

[1:31] I'm going to go over here and create a new Lambda function. I'm going to call this one a listBooksLambda. It's going to be a new lambda.Function. The first argument is this. The second one is "listBooksHandler". It takes a couple of arguments.

[1:46] First of all, we have to specify where the code for the function is. This is lambda.Code.fromAsset("functions"). This is the place where are we going to store all of our Lambda functions. Next up, we have to specify a runtime. This function is going to use a lambda.Runtime.NODEJS_14_X.

[2:05] Lastly, we need to specify a handler. I'm going to call this one a "listBooks.Handler". Now, we have to implement this function. Let me go over here. I'm going to create a new folder which is going to be called Functions. This name has to match this one.

[2:20] I'm going to create a new file, listBooks.ts. Inside of it, we're going to implement the body of our listBooksLambda function. For the time being, I'm going to paste in a body of a function, which always returns a list of two books with an ID, title, completed, rating, and some reviews.

[2:37] With that implemented, let me go back to our stack. We're going to connect this Lambda function with this AppSync API. To do that, we're going to create a data source, so const listBooksDataSource, and this is an api.addLambdaDataSource.

[2:52] There are two arguments here. First of all, I'm going to assign it an ID of listBooksDataSource. The second argument is the Lambda function that needs to be attached to this data source. In our case, this is the listBooksLambda, so let me just copy and paste that over here.

[3:06] Lastly, we need to make sure that this data source is going to be invoked whenever we send a GraphQL query to list all the books, such that I'm going to create a resolver.

[3:15] This function takes an object as a argument. First argument is the typeName, which I'm going to set to Query. I'm going to set the fieldName to listBooks. What that is saying is that whenever there's a query to listBooks, I would like you to use this data source, which in turn is going to call the listBooksLambda, which in turn is going to return those two books.

[3:38] With everything connected together, let us open up the terminal and run cdk diff to understand what are we about to deploy. There's a number of things here, but the most important ones is that the listBooksHandler function is going to be created. Also, we're going to have an AppSync resolver as well as a data source. Let's deploy it.

[3:57] To do that, run cdk deploy. Before we can deploy, because we are allowing an AppSync API to call a Lambda function, CDK double-checks whether we are OK with all of those changes. We definitely are, so I'm going to hit Yes and hit Enter.

[4:12] The deployment was successful, so it's time to test that. I'm going to navigate back to GraphQL Playground and hit Play. Success, we are getting a list of two books. Notice that because we're using GraphQL, we are getting only the fields that we asked for and nothing more and nothing less.

https://app.egghead.io/api/v1/lessons/graphql-connect-an-aws-lambda-data-source-to-an-appsync-graphql-api/transcript

https://app.egghead.io/api/v1/lessons/aws-create-a-dynamodb-table-in-an-aws-cdk-app/subtitles

Tomasz Łakomy: [0:01] Hard coding data in a Lambda function is not exactly the best practice. We probably need a database. Let's go back to our stack and create a DynamoDB table. We don't have a construct for DynamoDB table yet, so we have to install it. To do that, we're going to open up the terminal and run npm install @aws-cdk/aws-dynamodb.

[0:20] With that done, let me go ahead and import it again. I'm going to just copy that and change lambda to dynamodb, like this. Next, we're going to create a table to store our books. I'm going to go over here and do const booksTable, which is a new dynamodb.table, and the first argument is this. I'm going to call it a "BooksTable", because it's going to store books.

[0:41] There's a number of props that we need to pass in. First of all, I'm going to set the partitionKey to be an id. Its type is going to be a dynamodb.AttributeType, and it's going to be a STRING. The reason for that is that I would like to have this id match the ID type in our graphql schema. This id is in fact a string. That is why this partitionKey for our BooksTable is also a string.

[1:06] I'm going to try one more thing. I'm going to add a billingMode which I'm going to set to dynamodb.BillingMode.PAY_PER_REQUEST. Now, with the DynamoDB table in place, we need to be able to tell the listBooksLambda where it can find all the books.

[1:21] In order to do that, I'm going to create an environment variable which I'm going to call BOOKS_TABLE. I'm going to set it to booksTable.tableName. This will ensure that in the code for our Lambda function, I will be always able to read the variable of BOOKS_TABLE in order to get the tableName of our booksTable.

[1:40] There's one more thing that we need to do. We need to tell AWS that it is OK for this Lambda to read the data from this booksTable, because by default, AWS is following the principle of least privilege. The idea is that all the resources should have the minimal amount of privileges in order to do their job.

[1:59] By default, this Lambda function cannot read the data from this table, but if I do booksTable.grantReadData(), and I'm going to provide this Lambda function here, this will ensure that the listBooksLambda can read the data from booksTable. Note that I'm only giving read access for this Lambda function because listBooks doesn't need to be able to write any data into our table.

[2:22] With all of that in place, let me run cdk deploy in order to deploy our stack to AWS. Again, it's going to ask me whether I'm OK with those changes. If we take a look over here, this is saying, do we want the listBooksHandler to be able to, for instance, get items from this table?

[2:40] Yes, we are OK with that. I'm going to hit yes and hit Enter. After this is done, let us verify our deployment. I'm going to navigate to AWS Console, and I'm going to navigate to CloudFormation Console.

[2:51] Next, I'm going to click on our stack name and go to Resources. Here, I'm going to search for dynamodb. Apparently, we do have a DynamoDB table created. I'm going to click on its id in order to navigate to it. Hear it is, we do have a DynamoDB table created.

[3:07] Let us view its items by clicking on this button over here. Apparently, this table is empty. For the time being, let us create two items. To simplify things a bit, I am not going to use this web form, but instead, I'm going to navigate to JSON, and just paste a JSON object for the first book, create it, and we can see this book over here.

[3:24] Now, I'm going to create another item, which is going to be another book, and hit Create item again. We have our DynamoDB table pre-populated with two books.

https://app.egghead.io/api/v1/lessons/aws-create-a-dynamodb-table-in-an-aws-cdk-app/transcript

https://app.egghead.io/api/v1/lessons/aws-read-data-from-a-dynamodb-table-in-an-aws-lambda-resolver/subtitles

Tomasz Łakomy: [0:00] Since we have created a DynamoDB table, it makes sense to fetch data from it, as opposed to hard-coding the data in our Lambda function. As such, I'm going to remove all of that, and we're going to implement this function again.

[0:13] In order to fetch data from DynamoDB in our Lambda function, we are going to need the AWS software development kit. In order to install it, run, npm install aws-sdk. I'm also going to install the types for AWS Lambda.

[0:27] With that installed, let us go back to our function. This function is supposed to return a list of all of those books. In order to do that, we're going to need to create a TypeScript type. I'm going to create a type, book, which is going to be, more or less, the representation of this, but in TypeScript.

[0:45] It's going to have an ID, which is a string. It's going to have a title, which is also a string. It's going to have a completed flag, which is optional, and it's a Boolean. It's going to have a rating, which is a number. It's going to have reviews, which is an array of string. A rating is also optional.

[1:02] We are going to need one more type. Currently, this handler is just an asynchronous Typescript function, whereas it is actually an AppSyncResolver. As such it should have a proper type. Let me import it. I'm going to do import from AWS Lambda. I'm going to get a type which is called AppSyncResolverHandler. This one.

[1:21] We're going to change the type of this handler to be of AppSyncResolverHandler. This is a generic type. The first argument to this generic type is whatever is the argument to this function. This function is not going to take any arguments. The second argument is the return value.

[1:37] This function can either return an array of books or it can return null. Currently, it is complaining because this function is not returning anything. Let's fix that. To start, we are going to read the data from a DynamoDB table, which may or may not succeed. As such, it is better to always wrap something like this in a try-catch.

[1:55] Whenever there's an error, I'm going to just console.error "Whoops" and just display this error. I'm going to return null. Next up, in order to read the data from DynamoDB, I'm going to import DynamoDB from AWS SDK.

[2:10] Next up, I'm going to create a new instance of documentClient, which is a new DynamoDB documentClient. A documentClient is essentially a simpler API for us to interact with DynamoDB API from our TypeScript code. With that, let us list all the books. I'm going to do cons data which is going to be equal await documentClient.

[2:32] I would like to use the scan operation in order to scan the entire table and get everything that is inside of it. A scan operation takes a TableName as an argument. This is a small problem. How do I know which table am I supposed to read from inside of this function?

[2:48] If you recall in our CDK stack, what we did is that we have passed an environment variable of BOOKS_TABLE to this function. Now is the time to use that. I'm going to do process.env.BOOKS_TABLE. In order to make the scan function to work with an await keyword, I have to return a promise.

[3:07] Now, I can return data.Items. I'm going to assign them as type of Book. TypeScript is complaining right now because the table name may or may not be specified. It has no way of knowing that this BOOKS_TABLE was passed into this function. I'm going to do something else.

[3:23] I'm going to add an if statement that if this BOOKS_TABLE is not defined, I'm going to log out an error, BOOKS_TABLE was not specified. I'm going to also return null. Right now, everything is fine. Typescript is not complaining.

[3:36] Two small things to notice. First of all, this is using a scan operation which is going to go for the entire DynamoDB table and return every single item that's inside of it. This can be costly for large tables. Currently, our table is very small so this is fine.

[3:51] Secondly, I had to use this type assertion over here. The reason for that is that TypeScript has no way of knowing that what we are going to store in this DynamoDB table are books. That is why we have to tell TypeScript first, "Hey, those items, this is going to be a list of books. This Book type is something that we have defined over here."

[4:10] Since our function is finished, now we can deploy it. I'm going to run CDK deploy in my terminal. OK. It was successfully deployed. As a reminder, in our DynamoDB table, we have two books. We have "A Philosophy of Software Design" and "Atomic Habits." Both of them, I highly recommend by the way.

[4:26] Let's test our newly implemented Lambda function. I'm going to paste in a GraphQL query which is supposed to list all the books with their IDs, title, rating, and so on. If I hit Play, we're going to see that our Lambda function has been successfully called. This Lambda function was able to bridge the data in DynamoDB table in order to fetch both of those books.

https://app.egghead.io/api/v1/lessons/aws-read-data-from-a-dynamodb-table-in-an-aws-lambda-resolver/transcript

https://app.egghead.io/api/v1/lessons/graphql-generate-typescript-types-from-a-graphql-schema/subtitles

Tomasz Łakomy: [0:00] There's a small problem with our listBooks implementation. The problem is that I had to, effectively, recreate the book type from our GraphQL schema. For instance, if I wanted to include another field for the name for the author, I would have to do it in two places. If I'm going to have more Lambda functions in this API, this is going to get out of hand really quickly.

[0:20] It's better to auto-generate TypeScript types from the GraphQL schema. In order to auto-generate our types from the GraphQL schema, we need to install two packages, so @graphql-codegen/cli and @graphql-codegen/typescript. Let me hit Enter and start installing those.

[0:38] After this is done, create a new file in the project and call it codegen.yaml. I'm going to take the liberty of copying and pasting its content. This file is going to take the schema which is defined in the GraphQL directory over here, schema.graphql, and is going to generate TypeScript types based on this schema. Those types are going to be located in the file, which is going to be called books.d.ts.

[1:03] Next up, navigate to package.json, and we're going to add one more NPM script. I'm going to create a script called codegen, which is going to run, GraphQL Codegen. Let me fix the typo and let's give it a shot. Open up the terminal and run, npm run codegen. Apparently, this command did generate the output.

[1:22] Let me navigate to the types folder over here, and let's see the TypeScript types that were generated for us. For instance, here, we can see the type for a book. It's slightly more complicated than the type that we had before. The bottom line is, is that we didn't have to create this type our self. It's much easier and much quicker for the computer to generate those types for us.

[1:44] In fact, let us go back to our Lambda function. I'm going to delete the type for a book. We are no longer going to need that. Instead, I'm going to import this type from the file that we have just created. We can see that TypeScript has not found any errors, and we can continue using this auto-generated type in our code.

https://app.egghead.io/api/v1/lessons/graphql-generate-typescript-types-from-a-graphql-schema/transcript

By default, JavaScript allows you to mutate global objects. We've seen how when you call `lockdown()` from the ses library that it makes all of JavaScript's shared global objects immutable. 

This is great, but the rest of our JavaScript code that we write can still be tampered with.

Say we have this counter object that holds some state and has methods for incrementing and decrementing that state. 

```js
const makeCounter = () => {
  let count = 0;
  return {
    count,
    incr() {
      this.count += 1
      return this.count;
      },
    decr() {
      this.count -= 1
      return this.count;
      },
  };
};

const myCounter = makeCounter();
myCounter.incr();
myCounter.incr();
myCounter.incr();
myCounter.decr();
console.log(myCounter); // { count: 2, incr: {}, decr: {} }

```

Someone can come in and mutate our object. 
  
```js
const myCounter = makeCounter();
myCounter.incr();
myCounter.incr();
myCounter.count = 'hehehehe';
myCounter.incr();
myCounter.decr();
console.log(myCounter); // { count: NaN, incr: {}, decr: {} }
```

This completely breaks our program. The first thing we can do to prevent this type of tampering is to make `count private`.

```js
const makeCounter = () => {
  let count = 0;
  return {
    incr() {
      this.count += 1
      return this.count;
      },
    decr() {
      this.count -= 1
      return this.count;
      },
  };
};

const myCounter = makeCounter();
myCounter.incr();
myCounter.incr();
myCounter.incr();
myCounter.count = 'hehehehe';
myCounter.decr();
const lastValue = myCounter.incr();
console.log({lastValue}); // { lasValue: 3 }
```

This prevents us from directly accessing `count` and mutating it but we can still mutate our methods.

```js
const myCounter = makeCounter();
myCounter.incr();
myCounter.incr();
myCounter.incr();
myCounter.incr = () => {
  console.log('I have hijacked your increment. There is nothing you can do.');
};
myCounter.decr();
const lastValue = myCounter.incr();
console.log({lastValue}); // { lasValue: undefined }
```

These methods need to be accessible to people because that's the API we want to expose so we can't just make them private.

We can use the `harden` function from the ses library to make our methods tamper-proof.

```js
const makeCounter = () => {
  let count = 0;
  return harden({
    incr() {
      this.count += 1
      return this.count;
      },
    decr() {
      this.count -= 1
      return this.count;
      },
  });
};
```

This locks down the object and prevents anyone from mutating it. Now if you try to reassign `incr` you'll get an error telling you `TypeError: Cannot assign to read only property 'incr' of object '[object Object]'`.

https://app.egghead.io/api/v1/lessons/graphql-perform-a-graphql-mutation-with-an-aws-lambda-function/subtitles

Prevent JavaScript Object Tampering with the SES Library harden Function

[00:00] In this file we have the sess library being imported and What we're going to do here is just invoke the lockdown Function it gives us access to now by calling lockdown We are introducing a few different changes to our program

[00:18] One of those is that we are making all of JavaScript's shared global objects Immutable so as a result these is frozen checks are going to return true for us And if we remove them, we'll see that they quickly revert back to being false

[00:37] This is great as we've made our global objects immutable But let's see how we can continue and make the rest of our JavaScript code tamper-proof So here, I'm just creating a make counter function and then inside here I'll initialize a count variable to be zero

[01:01] And then we're just going to return this Alongside methods for incrementing and decrementing And so our increment method is Is going to shockingly Increase the count by one each time. It's called while decrement is going to take one away from work

[01:28] Now that we have that wired up. It's going to create this my counter variable using our make counter function and Then I'm going to Invoke the increment and decrement methods a few times and Lastly, we'll just log out my counter to see what we're working with

[01:53] If we take a look in the console we see that count is two and Three minus one equals two so our math checks out there Everything is Going smoothly, but oh no Somewhere along in our program My counter was mutated

[02:15] The count property is now this string of he he's and So this is less than ideal as we'll find our count variable is now Showing us not a number So what changes can we make to prevent this? so for one let's

[02:35] Stop returning this count property altogether Let's make it private to our function Now instead of using the this keyword we can just operate directly on this count all right, so now I'm just going to create a last value variable and set it equal to

[02:59] the result of my counter dot increment and now if we look in the console we see that we've successfully prevented our program From running into such issues as Last value is printing the correct value So we're moving in the right direction but let's see what happens if we

[03:23] Try to actually mutate one of our methods and here. I'm just going to change our increment and For right now, we're just going to have it log out the statement I

[03:39] Have hijacked your increment it. There's nothing you can do and I'm just going to place this above any other Increment thins to really screw things up here and if we look oh, I need to correctly mutate this and

[04:00] Remove this parentheses here Now that that's fixed if we inspect our council Oh We see that this message is shown for us over and over and over again So not good as we still have some holes we need to plug and

[04:26] This is where the sass library can help us once again Specifically we can turn to this harden function Which is going to be made globally available to us once lockdown is invoked Harden is going to take objects and work to them recursively

[04:50] making each property tamper proof so here we can see that we're just using it to make our counters methods tamper proof and The result of this is that Our code now throws an error Saying cannot assign to read-only property Incra

[05:12] so now let's remove this because we can no longer change the value of anything within our my counter object and Now if we go back, we'll see that our program is behaving correctly again

https://app.egghead.io/api/v1/lessons/graphql-perform-a-graphql-mutation-with-an-aws-lambda-function/transcript

https://app.egghead.io/api/v1/lessons/aws-reduce-the-latency-of-your-aws-lambda-functions/subtitles

Tomasz Łakomy: [0:00] Let's talk about performance. I haven't called this API in a while. If I hit Play, you will notice that the request is taking some time to return. If I hit Play again, now it's much faster. Let's investigate what exactly is happening here.

[0:15] To investigate the latency of our function, let us go back to AWS Console. I'm going to navigate to the CloudFormation console, and next, I'm going to navigate to my stack. Next up, I'm going to click on Resources and search for a Lambda. We can see two Lambda functions here. I'm going to click on the listBooks handler.

[0:33] Here, in the Lambda console, we can see the source code of our function, transpiled from TypeScript to JavaScript. What I care about are the logs. I'm going to click on Monitor, and next, click on View Logs in CloudWatch. Here, we can see the logs for our listBooks handler.

[0:49] First, let me scroll down to the newest log stream. Those are the logs of our Lambda function. At the end of each invocation, there's a report. Here, for instance, we can see that this particular invocation took 709 milliseconds.

[1:03] Because this was a cold start, the Init Duration was close to 400 milliseconds. This is a bit slow. It's getting a bit better once the function is warm. For instance, in this particular invocation, it took 83 milliseconds. There was no cold start.

[1:18] There's a way to improve the performance of a Lambda function. Note that currently, the memory size assigned to this function is 128 megabytes, which is frankly not a lot. In fact, this Lambda function is using 78 megabytes of its memory.

[1:32] Let's increase the memory available for this function. To do that, go back to our stack. Inside of listBooksLambda, I'm going to also specify the memory size, which is a number. I'm going to provide it with a gigabyte of memory, 1024 megabytes. If I save that, I can go ahead and deploy it.

[1:52] After it's done, go back to the Lambda console. Here, I can click on Configuration in order to verify that my function now has a whole gigabyte of memory available to it.

[2:02] Let's test if there's any improvement. Go back to our GraphQL Client. I'm going to invoke this function a bunch of times. Go back to Monitor. Click on View Logs in CloudWatch once again. Click on the newest log stream. I'm going to expand all of that.

[2:17] Here, we can see that even though we did hit a cold start, the duration of the function was 85 milliseconds, which is much faster. Here, we can see that the memory available for this function was a whole gigabyte.

[2:31] Again, the max memory used by this function was roughly 77, 78 megabytes. It gets even better once there's no cold start. Those last few executions were around 23, 28, and 22 milliseconds, which is rather fast.

https://app.egghead.io/api/v1/lessons/aws-reduce-the-latency-of-your-aws-lambda-functions/transcript

https://app.egghead.io/api/v1/lessons/graphql-query-for-aws-dynamodb-items-by-id-with-an-appsync-graphql-api/subtitles

Tomasz Łakomy: [0:00] Currently, I'm only able to get all of the books. What if I wanted to get just a single book by its ID? Let's Implement that. First of all, we need to add another query to our graphql schema. I'm going to add a getBookById(). This is going to take a bookId as an argument, which is of type ID!, and is going to return a Book or null, if a book could not be located. Let me save that.

[0:23] Next, let's update our TypeScript types. To do that, open up the terminal, and I'm going to run npm run codegen. Let's take a look at our new types. Here, we can see the getBookById type, as well as QueryGetBookByIdArgs. We are going to use this type in our Lambda function.

[0:42] To create the Lambda function, let us go back to our stack. In terms of CDK stack, our getBookById function is going to be quite similar to the listBooks function. I'm going to just copy all of that, paste it over here, and let us just amend it. Instead of listBooks, I'm going to select all of that and change it to getBookById.

[1:04] To double-check, this is going to create a getBookById Lambda which is going to be implemented in a getBookById file. This is going to grant this function ReadData to DynamoDB. This is going to create a new data source for our AppSync API. This is going to make sure that whenever we query for getBookById, this Lambda function is going to be executed.

[1:25] Let's implement this function. I'm going to go to my functions and create a getBookById.ts file. Again, I'm going to start with an empty handler. Let me add the necessary imports. We need the AppSyncResolverHandler. Also, we need a type for a Book. Also, this QueryGetBookByIdArgs which we are going to use in just a second, as well as DynamoDB.

[1:47] Next up, let me create the documentClient. This is DynamoDB.DocumentClient. This has to be a new DynamoDB.DocumentClient. We need to specify the type for this handler function. It's going to be an AppSyncResolverHandler. Again, this is a generic type.

[2:03] The first argument of it are the arguments to this function. This is QueryGetBookByIdArgs. The second argument to this generic type is what is going to be returned from the function. It's going to be either a Book or null.

[2:15] In order to get a book by id, we need the id. I'm going to create a bookId which is going to be equal to event.arguments.bookId. Next, we need to fetch a book with this id from DynamoDB. That's going to be quite similar to other functions.

[2:31] If a BOOKS_TABLE is not specified, we want to return null. If something explodes, we want to also return null and just catch this error. Let me remove this null over here. Let us implement this behavior.

[2:41] In order to get an item from DynamoDB, I'm going to do await documentClient.get(). This function takes an object as argument. The first argument is TableName which is process.env.BOOKS_TABLE. The second argument is the Key. This Key is the partition key of this DynamoDB table.

[3:00] If you recall, in our stack over here where we defined the BOOKS_TABLE, we set the partitionKey to be the id of a given book. Here, I need to pass in the id which is equal to bookId. This needs to also return a promise.

[3:16] I would like to return something. This return value should be the actual book. I'm going to do const. I'm going to get the Item. This Item is actually our book. This type assertion is mandatory because TypeScript has no way of knowing what exactly am I getting from this DynamoDB table.

[3:32] Time to deploy and test our function. Let me run cdk deploy.

[3:37] Let's test our newly added query. Instead of using this GraphQL client, I'm going to do something else. I'm going to navigate to AppsSync Console in AWS Console and click on the name of my API. First, let me go to Schema. Here on the list of resolvers. I can scroll down a bit and see the resolvers for both listBooks and getBookById queries.

[3:57] In fact, speaking of queries, let me click on Queries tab over here. Let me close that. I can also use this in AppSync Console in order to test my queries. Let me delete all of that and click on getBookById. I need to specify a bookId. For instance, I'm going to specify "123" because I know I have a book like this in my DynamoDB.

[4:16] I'm going to also get the title, id, rating, and reviews. I'm going to send this query. Voila, we do get the "Atomic Habits." What happens if I try to find a book which doesn't exist in our DynamoDB table? I can hit Play. It's going to be null because we don't have a book with this particular id.

https://app.egghead.io/api/v1/lessons/graphql-query-for-aws-dynamodb-items-by-id-with-an-appsync-graphql-api/transcript

https://app.egghead.io/api/v1/lessons/aws-refactor-aws-lambda-functions-to-use-arm-graviton2-architecture-in-cdk/subtitles

Tomasz Łakomy: [0:00] If we take a look at the definitions of our Lambda functions in CDK stack, you may notice that those props are quite similar. For instance, the environment variables are basically the same, as well as the runtime. In order to avoid repeating ourselves, let us extract all those props to a common object.

[0:17] In order to do that, above all of our Lambda functions, I'm going to create a commonLambdaProps. That is an object of type lambda.FunctionProps. The only thing that is truly unique about all of those functions is the handler. I'm going to copy everything else. I'm going to get all of that, paste that here, and remove the handler.

[0:37] TypeScript is complaining because handler is not defined in this object, but would like only the common parts to be in this object, and the handler is not exactly one of them. I'm going to change the type of this object to Omit<lambda.FunctionProps>, and I'm going to omit the "handler".

[0:52] Omit is a type that is provided by TypeScript, and it allows you to take a type -- in that example, the FunctionProps -- and omit one of its fields. In this case, this is the handler.

[1:03] With that prepared, I can go ahead and use these common Lambda props in all of those other Lambda functions. I can just spread all the common Lambda props. Let me repeat that for other Lambda functions, over here and also over here.

[1:21] Now, all of our Lambda functions are sharing those common Lambda props. For instance, if I wanted to bump the memory size of our Lambda functions, I can do that in a single place. In fact, let us try something.

[1:33] AWS has recently announced that AWS Lambda functions can be powered by AWS Graviton2 processor, which allows us to achieve up to 34 percent better price performance. This is good news because with Lambda, you are charged based on the number of requests for your functions and the duration. That is, the time it takes for your code to execute.

[1:53] If I switch to this brand-new architecture, the duration changes are 20 percent lower. This is a cost reduction with a single line of code. Let's give it a shot. I was not kidding with "a single line of code." The only thing that we need to change is the architecture prop to our common Lambda props. That is going to be equal to lambda.Architecture.ARM_64. That's it.

[2:15] Let us verify our changes. To do that, open up the terminal and run cdk diff. We can see that all of our handlers are going to be using the brand-new architecture for AWS Lambda functions.

[2:27] Changes like those are a huge benefit of CDK because it is very often the case that AWS releases something new and the only thing that you need to do in order to reap benefits from it is to add a single line of code in your CDK stack.

[2:41] Let's double check our stack by deploying it and calling our API. Everything works just fine. After we navigate to our Lambda function in AWS Console, if we scroll down in this createBookHandler page, we're going to see that the architecture was changed to arm64.

https://app.egghead.io/api/v1/lessons/aws-refactor-aws-lambda-functions-to-use-arm-graviton2-architecture-in-cdk/transcript

https://app.egghead.io/api/v1/lessons/aws-use-appsync-logging-and-aws-x-ray-to-debug-performance-issues/subtitles

Tomasz Łakomy: [0:00] A single GraphQL query can trigger multiple resolvers. For instance, in this example, this MyAwesomeQuery is listing all the books and also getting a single book by its ID. Of course, this works fine, but here's a problem. What happens when one of those resolvers is slow? How do we identify and fix a performance issue like this?

[0:20] Let me cause a performance issue. I'm going to add a wait function to my getBookByIDLambda function. This function is essentially going to hang the execution of this Lambda function by a timeout specified over here. Before we get an item from DynamoDB, I'm going to add a, wait 2000, hanging this function for two seconds.

[0:41] Because wait function returns a promise, I also need to await it. Let's deploy that. Let's give it a shot. I'm going to send this MyAwesomeQuery once more. You will notice that it is much slower. This is something that may happen in a production API. For some reason, it gets very slow, and now we have to investigate what is going on.

[1:04] To do that, let us go back to our stack. I'm going to scroll up to our AppSync API, and we're going to add two more things to it. First of all, we're going to add a logConfig in order to enable logging in our API. I'm going to set the fieldLogLevel to be of AppSync.FieldLogLevel.All because, for the time being, we would like to get as many logs as possible.

[1:25] On top of that, I'm going to also enable X-Ray. X-Ray is an AWS solution for enabling traces in our API, and I'm going to set it to true. With all of that, let us do another deployment.

[1:39] Let us investigate. We have a slow GraphQL query in our API. How do we find it? First of all, I'm going to navigate to the AppSync console. Next, I'm going to go to Settings to verify that, first of all, logging was enabled for this API and the log level is set to All, just in case.

[1:55] Here we can see that the X-Ray was successfully enabled for this API. Take a look at this note. It says that you may be charged for using X-Ray, so please keep that in mind.

[2:05] Let's start our investigation. Go to Monitoring tab, and next click on View Logs in CloudWatch. I'm going to close this section over here and expand all of the logs. As you can see, there's quite a lot of them.

[2:17] This is where the request started. We can see that it started at 17th second of a given minute. If I scroll down a bit, this is quite a lot of logs, we can see over here that this request has ended nearly three seconds later. In fact, this latency, which is in nanoseconds, tells us that it was 2.6 seconds later, so we definitely have a performance issue in this API.

[2:40] If I go to the top of the logs for this particular request, I can see that this query was sent to MyAPI. This MyAwesomeQuery was fetching a list of all of the books and also a single book by its ID. If I scroll down a bit, we're going to see all sorts of logs for this particular execution.

[2:58] What if I wanted to visualize what exactly is going on and which component is actually introducing latency in MyAPI? To do that, let us check the RequestSummary once again. I'm going to scroll down to it.

[3:10] Here we have an Amzn-Trace-Id for this particular request. I can copy that and go to the aforementioned X-Ray service. Here, I can paste in this trace ID and hit Enter in order to visualize it. This is going to create an interactive map of my request.

[3:27] There's a number of things here. First of all, down here in the bottom we see a timeline of everything that happened in MyAPI. I was trying to call this API. I got the response of 200. I was in fact calling two Lambda functions.

[3:41] This listBooksLambda managed to complete in 637 milliseconds, which was not terrible. The second Lambda actually took over two seconds in order to execute.

[3:51] Apart from the Timeline View, here we also have an interactive map of our system. A Client was calling our GraphQLAPI, which in turn was calling two Lambda functions.

[4:01] This Lambda function is the listBooks handler, which, as I mentioned, took roughly half a second in order to execute. The second Lambda, which is a getBookByID handler, took over two and a half seconds in order to complete. Now we know that we have to investigate this Lambda.

[4:17] Then we would probably have noticed that this wait call is not exactly a good idea. We should remove that, deploy again, and now our API is going to be fast once more.

https://app.egghead.io/api/v1/lessons/aws-use-appsync-logging-and-aws-x-ray-to-debug-performance-issues/transcript

https://app.egghead.io/api/v1/lessons/graphql-update-an-aws-dynamodb-item-using-a-third-party-library-in-a-lambda-function/subtitles

https://app.egghead.io/api/v1/lessons/graphql-update-an-aws-dynamodb-item-using-a-third-party-library-in-a-lambda-function/transcript

https://app.egghead.io/api/v1/lessons/graphql-add-a-graphql-subscription-to-an-aws-appsync-api/subtitles

Tomasz Łakomy: [0:00] Suppose we would like to be notified as soon as someone updates a book in our API. Luckily, AppSync supports GraphQL subscriptions out of the box which allows us to use WebSockets to achieve this exact behavior.

[0:12] In order to do that, we need to add a type Subscription. We would like to be notified whenever updateBook() is triggered. We're going to do onUpdateBook. It should return a book. In order to enable subscriptions in AppSync, we have to use a special directive.

[0:28] This directive is @aws_subscribe. We have to pass in a list of all the mutations that we want to subscribe to. In our case, this is mutations equals updateBook. That's it.

[0:40] With that in place, let us test that. We can run cdk deploy. Note that we don't have to write any custom code. AppSync is going to take care of the subscription for us. The easiest way to test our newly defined subscription is to go to AWS console, to AppSync. I'm going to click on Queries.

[0:57] Here in this drop-down, I'm going to select Subscription and click on the plus sign. We only have one subscription defined. I would like to get all of those fields whenever a book is updated.

[1:08] I'm going to hit play. Now, we can see that we are subscribed to this updateBook mutation over a WebSocket. I can go back to my GraphQL client and change the rating of this book to 10. We can see that without sending any additional requests, we did receive a subscription with an updated rating of this book.

[1:25] Let me update the title. I'm going to change the title to "This Book is Awesome." Let me send that and go back over here. We can see again, the title was updated. Thanks to the GraphQL subscription, we are notified as soon as it happens.

https://app.egghead.io/api/v1/lessons/graphql-add-a-graphql-subscription-to-an-aws-appsync-api/transcript

https://app.egghead.io/api/v1/lessons/graphql-delete-and-restore-an-aws-cdk-stack/subtitles

Tomasz Łakomy: [0:00] It's possible that our book API startup is not going to be a huge success. As such, we should learn how to delete a CDK stack.

[0:07] In order to delete a CDK stack, run cdk destroy. This is going to ask us if we want to delete the stack. Yes, we want to delete it. This is fine, by the way, because if you want to restore the stack, we simply have to deploy it again. This is going to take a second because it has to delete all the resources in our CloudFormation stack.

[0:25] Now it's gone, but let's double check. I'm going to go to AWS Console and navigate to CloudFormation. It seems that our stack was deleted because it's not here on the list. Suppose we got extra funding and we want to restore our stack. We can run cdk deploy again and this took a second because it had to recreate all the Lambda functions, DynamoDB table and so on.

[0:47] This is the power of CDK or infrastructure as code in general. We are always able to deploy our stack in a different AWS account, in a different region, with no manual steps required because everything is defined in code.

https://app.egghead.io/api/v1/lessons/graphql-delete-and-restore-an-aws-cdk-stack/transcript

Build a GraphQL API with AWS CDK and AppSync

Tomasz Łakomy

You might also like these resources:

Cloud Infrastructure Fundamentals with AWS

Designing GraphQL Schemas

Learn AWS Lambda from scratch

Credits

Course Content

You might also like these resources:

Cloud Infrastructure Fundamentals with AWS

Designing GraphQL Schemas

Learn AWS Lambda from scratch