Introduction to the AWS CDK: Infrastructure as Node

Rate this content
Bookmark

For years AWS has offered CloudFormation as an approach to Infrastructure as Code (IaC). CloudFormation allows application stacks to be provisioned from JSON or YAML formatted templates. Unfortunately, due to their size and complexity, CloudFormation templates have earned a reputation as being unwieldy to work with. The AWS Cloud Development Kid (CDK) mitigates some of the complexity associated with CloudFormation allowing developers to programmatically define their cloud architecture using familiar high-level languages such as JavaScript and TypeScript. CDK projects can then be deployed via CloudFormation, while retaining all of the benefits of CloudFormation, such as repeatable deployments and drift detection.


This talk will introduce the CDK in the context of Node.js and demonstrate how it can be leveraged to provision cloud native architectures.

34 min
01 Jul, 2021

Video Summary and Transcription

The AWS CDK is an infrastructure as code tool that supports multiple programming languages and helps mitigate concerns about vendor lock-in. It uses JSII to support different languages and allows you to write code once and get the same API across different languages. The CDK simplifies resource creation and management in AWS, addressing the verbosity and error-proneness of CloudFormation. CDK applications consist of apps and stacks, with stacks mapping to CloudFormation stacks. The CDK provides a more compact and familiar syntax compared to CloudFormation, making it easier for JavaScript developers to handle the entire stack.

Available in Español

1. Introduction to the AWS CDK

Short description:

The AWS CDK is an AWS-specific infrastructure as code tool that supports multiple programming languages. It allows you to write your infrastructure and applications using the same tools and languages. The CDK offers testable infrastructure and helps mitigate concerns about vendor lock-in.

Hi, everybody. Thank you for virtually attending my talk. I'm going to be talking about the AWS CDK today, and the title of my talk is Introduction to the AWS CDK Infrastructure as Node.

So I guess the very first question to answer is, what is the CDK? So that's an abbreviation for Cloud Development Kit. It is an AWS-specific infrastructure as code tool. It's similar to tools like Terraform that you may have used in the past. It supports a variety of languages, so you can write your applications in JavaScript, TypeScript, Python, Java, and C Sharp. I believe there are plans for other languages in the future as well.

And the way that it works under the hood is that high-level JavaScript or TypeScript classes map to these things called CloudFormation templates, which I'll talk about again in a couple of minutes. If you've used the AWS SDK in the past, the CDK is not the same thing. The AWS SDK is used for making simple API calls, whereas the CDK is actually able to maintain state about your application, allowing you to update it and redeploy it without having to go through the same checks that you would if you were just making direct API calls. The CDK itself is fairly new. It reached general availability in the middle of 2019, so there are still some AWS features that are not supported yet, since AWS is quite massive. And then it's also free to use, but I've included an asterisk here because while the CDK itself is free to use, if you start using it to deploy things like EC2 instances or other AWS resources, you will be billed for those things.

So I guess next, you might be asking, why would I use this? So as I said before, there are lots of tools out there like this, things like Terraform and whatnot. So I'm going to actually reference a report from the Cloud Native Computing Foundation that surveyed approximately 17,000 developers. If you disagree with these quotes, please don't shoot me. I'm just the messenger. But JavaScript is the most popular server-side programming language among cloud-native developers. And 62% of cloud-native developers are using AWS as their cloud hosting provider. So the CDK really meets developers where they're at. There's already a lot of developers out there that are writing applications in the cloud with JavaScript and TypeScript and deploying them to AWS. By using a tool like this, you can write your infrastructure as well as your applications using the same tools and languages. And that's always been one of the upsides to Node.js was that it allowed frontend and backend developers to use the same common language. And this just extends that even further into your deployment in ops. The CDK also offers you testable infrastructure. So there is an AWS CDK-slash-assert module. It integrates really well with Jest and snapshot testing. And then the last thing I wanted to mention is you really shouldn't worry about vendor lock-in because you're probably already locked in. Unless you have the most extremely trivial app being able to go from AWS to something like Azure, it is probably going to require some effort importing.

2. Introduction to the CDK and JSII

Short description:

The CDK is not going to lock you in. The CDK uses JSII, a tool that allows it to be written in TypeScript but still supported by other languages. JSII executes TypeScript code and sends input/output as JSON between the node child process and the host process. This allows you to write code once and get the same API across different languages.

So the CDK is not going to lock you in any more than you're kind of already locked in. And then before I dive in a little too much further, I wanted to something that I found out while I was researching the CDK that I thought was kind of interesting. What is something called the JSII, which stands for the JavaScript interoperability interface. And this is kind of the tool that sits underneath the CDK that allows it to be written in TypeScript, but still supported by all the other languages that I named earlier. And when I originally read about this, I thought that it probably worked by just generating code that was kind of language specific, but actually under the on the node.js runtime. And what it does is it will execute your TypeScript code and send it back and forth, the input and output back and forth as JSON between the node child process and whatever host process has been running your application. And so there are some generated bindings that are part of the CDK output. So you can write your code once and you'll get the same API across all of these different languages. And that does unfortunately come with a performance hit because you're spawning a node process, you're interacting with a child process instead of generating the code directly. But I just thought that that was something that was kind of cool and wanted to share as part of this talk.

3. Introduction to CloudFormation and CDK

Short description:

CloudFormation is a powerful AWS service for defining and managing resources in the cloud. It simplifies resource creation, management, and maintenance, and supports inputs and outputs for passing parameters and generating outputs. However, CloudFormation can be verbose and error-prone. To address this, the CDK introduces an API using TypeScript and constructs as building blocks for composing CDK applications.

So back to the overall point of this talk. So I had mentioned CloudFormation earlier. CloudFormation is a well-known AWS service that basically allows you to define your architecture, your resources that you'll be using in the cloud as a JSON or a YAML template file. And then it can be deployed to be in the CloudFormation service.

It will take care of creating all of the resources for you that you need, such as instances or lambda functions or anything like that. And it can actually manage large groups of resources as a single unit, which is called a stack. And so stacks can be created. They can be updated and modified. They can also be deleted, and everything happens to that entire group as one single entity. So it makes the maintenance overhead a lot simpler for developers.

And as I kind of alluded to earlier, the fact that it maintains state between your deployments allows it to be much more powerful than individual AWS SDK calls where you would kind of have to manage all that state yourself. And then within CloudFormation, there are basically inputs and outputs to your CloudFormation stack. The inputs are called parameters. And these are good for passing in things like sensitive information, or if you were deploying a website, maybe what the domain name is for that stack and things of that nature. And then it can also generate outputs. So if you tell it to provision an S3 bucket, you might not know what the name of that bucket is ahead of time. So that can be used as an output, which can then be imported by another CloudFormation stack. So you can see that it's kind of composable and very powerful. But the biggest drawback is that CloudFormation is very verbose. So to maintain these JSON and YAML files by hand can actually be quite a bit of work. And it's very error-prone.

So the CDK saw the power of CloudFormation and introduced this API on top of it using TypeScript. And what it does is it gives you these building blocks called constructs. Constructs are kind of the way that you build and compose together CDK applications. And there are a variety of different types of constructs at different levels. So for example, the level one construct, these are basically CloudFormation resources. CFN here stands for CloudFormation in shorthand. So for an example, there is a CDK construct called CloudFormation bucket. And this is just, as bare bones as a wrapper around CloudFormation as you can get. But then level two constructs kind of take that up a level to introduce an intent based API.

4. Introduction to CDK Applications and Stacks

Short description:

Instead of a CloudFormation bucket, you might use an S3 bucket with a more user-friendly API. Patterns can compose different components together and accelerate productivity. CDK applications consist of apps and stacks, with stacks mapping to CloudFormation stacks. Each stack is configured by an environment, which includes an AWS account ID and region. Providing the environment can be done through code, command line flags, or environment variables. Generating a CDK application can be done using the 'mpx aws-cdk init app' command with the desired language.

So, building on the same example, instead of a CloudFormation bucket, you might use an S3 bucket. And this has a much more kind of user-friendly API. And then finally, there are what are called patterns, which are even higher level and can compose a lot of different components together. These can really accelerate your productivity.

So, for example, you can, instead of having to create Lambda functions, wire them up to an API gateway and things like that, you can just use the Lambda REST API pattern. And like I said, it can really accelerate productivity. And so the way that these applications work are you take your various constructs and you compose them into what's called a construct tree. And then it's also worth pointing out that AWS provides a large number of constructs from their library, but it's also possible for user land to create their own constructs to be more tailored to their needs.

So there are, I guess two special kinds of constructs that are worth discussing a little bit. There's our apps and stacks. So the root of the construct tree is always going to be an app component. The reason it's called an app is because CDK applications are referred to as apps. Like I said, this is always going to be the root, but then stacks are constructs that map to CloudFormation stacks. So I mentioned that, in CloudFormation, groups of resources are kind of grouped together as a stack and this is kind of a one-to-one mapping there. So apps contain stacks. You can have more than one in a single app, and then the stacks are usually what contain the other constructs. One thing worth pointing out is that each stack is configured by an environment, and I'll talk about that right now.

So an environment is an AWS account ID plus a region where the stack is going to be deployed. So this is basically saying this user is deploying to this region in the cloud. And so, an environment has to be provided for every region that you're trying to deploy to, and for every separate account that might want to deploy your stack. If you don't specify an environment, then the stack is what's considered to be environment agnostic, but these are pretty limited use. And then to provide the environment, if you've ever worked with any of the AWS tools before, there's a variety of ways to do this. In the code itself, you can pass in values to the stack constructor, but you can also pass in a profile flag from the command line or specify different environment variables, and it will automatically pick those up in the code and know where to deploy your stuff. You can also set up your AWS profile so that you have a default environment. But that's more of a local development type of use case.

So with all of that, I think we can actually generate our first CDK application. So I've added a simple command line up here using mpx, so you don't actually have to install anything yet. mpx aws-cdk, that is the name of the the module. init, app, and then we're passing the language. We want to use JavaScript here, but you can pass any of the other supported languages.

5. CDK Application Skeleton and Deployment

Short description:

This part explains how the CDK creates a full application skeleton and the process of synthesizing and deploying CDK applications. It also covers the concept of the construct tree, adding more constructs to the stack, and the workflow of the CDK CLI commands.

And so this will create a full application skeleton for you. One note is that you have to run this from inside of an empty directory so that it doesn't accidentally overwrite anything that might exist. And so this creates a bin folder, and so you can actually run this file directly. You can see the little shebang at the top of the code here that most node binaries include. So what this does is it imports a test stack that was also generated for you, instantiates your application with the new cdk.app constructor, and then it just creates a new test stack, and within the test stack you can see it passes the app as the first argument. So that is how the construct tree keeps track of which constructs are children of which other constructs.

And then we're going to be calling this one test stack, so that's what the second option is there. So looking at the stack itself, you can see this is the code that was generated. I left in some of the comments and other things that were automatically generated, but in future examples I'll be removing those to save space. So the first thing that we do is import the CDK itself, and then we create a test stack class, which extends the CDK stack base class. The constructor for a class takes a scope, an ID, and props. The scope is the parent construct, as I mentioned before. The logical idea of the construct is going to be when we synthesize and deploy these applications. And then props are an optional map that can be passed in that are used to define other properties of your construct. So if we wanted to add more constructs, then we could do something like this. NPM install dash dash save AWS CDK slash AWS EC2. This will basically install the CDK constructs for the EC2 service. In this simple example I'm adding a VPC to our stack. The reason I'm doing this is because VPCs can be deployed at no additional charge. So if you wanted to experiment with this at all and deploy it, you should be able to run this without actually incurring any charges.

So next I wanted to talk about how these applications are kind of synthesized and deployed. So you can see we have the overall workflow here. You'll see cdk-cli at the top. cdk-deploy is one of the CLI commands. I'll talk about what some of the other ones are later. And what it does is it reads in your application source code. It goes through what's called the construct phase, where user code is run and all the constructor chain is executed, so it's basically building the construct tree. The prepare and validate phases are hooks that are available to constructs, but they're generally not needed and sometimes they're actively discouraged. And then next comes the synthesis phase, which generates something called a cloud assembly. The cloud assembly is going to be your cloud formation template as well as any other deployment artifacts that are needed to deploy your app to the cloud.

6. Deployment Process and CloudFormation Template

Short description:

The deploy process takes your cloud assembly and uploads any necessary artifacts to the cloud for a cloud formation deployment. The synthesizing step can be done separately for local testing and unit tests using the MPX AWS CDK synth command. It generates a cloud formation template and deployment artifacts, such as Docker images. The output is written to standard outputs and the cdk.out directory. The cloud formation template can be verbose, especially compared to the concise CDK app code.

And I'll talk about what those other deployment artifacts are in a little while. And then the deploy will actually take your cloud assembly and upload anything that needs to be uploaded to the cloud and start a cloud formation deployment. And once that succeeds then you have a CDK app that is actually deployed to the cloud. You can actually do the synthesizing step as a separate step without needing to deploy it, which is nice for like local testing and unit tests. So you would do that via the MPX AWS CDK synth and then the name of your stack.

So in this case test stack, this will generate, it'll translate your CDK app into a cloud formation template. It'll generate any of the deployment artifacts such as Docker images, if you're deploying any lambdas, it will bundle those up for you. And then it'll write everything to both standard outputs, since this is just a synthesis and not a deployment. But we'll also create your cdk.out directory, which is where everything is kind of stored before it's deployed. And then you can see to the right here, I actually have captured what the cloud formation template looks like. And you can see that it's taking up the entire height of the slide and is very unreadable. And that's based on a cdk app that was roughly a dozen lines of JavaScript. So you can see where the increased verbosity comes from with cloud formation as well as the expressive power of the cdk.

7. Assets, Bootstrapping, and CLI

Short description:

Assets and bootstrapping are important concepts in CDK. Assets are local files or directories that need to be uploaded to S3 or Docker images uploaded to the Elastic Container Registry. Bootstrapping is necessary for deploying assets per environment. A realistic example is deploying a static S3 site, where a new stack is created with an S3 bucket. Deploying the site requires bootstrapping the environment. Adding DNS or CDN can enhance the static site. To clean up, use the CDK destroy command and check the web console for AWS resources. The CLI provides all the necessary commands for deployment.

Next, I wanted to talk about assets and bootstrapping. So any local files or directories that need to be uploaded to S3 or any local Docker images that need to be uploaded to the Elastic Container Registry are known as assets. If your application uses any of these assets, then you'll have to do something called bootstrapping which is something that has to be done per environment. So per user and region combination. It will also create an additional cloud formation stack for you called cdk-toolkit. And it consists of an S3 bucket and an IAM set of resources for deploying the assets to the cloud.

One thing to note is that you will likely be charged for this because you'll be storing assets in AWS. So I wanted to look at a more realistic example now where we'll deploy a static S3 site. I included an asterisk here because again you will be charged by AWS if you run this. I've created a new stack here called the website stack which extends the CDK stack class and then inside I'm creating a new S3 bucket. So I'm going to call my bucket website bucket. I'm going to make index.html the the index page for my site that I'm deploying and I'm going to grant public read access to the world so that anybody can can come and view my site. And then to deploy it I'll use the S3 deployment bucket deployment construct so I'm attaching it to the stack I'm calling this deployment my website. The sources are going to come from a local directory that I'm calling www that will actually create assets as I mentioned in the previous slide, that's the part that you're going to be charged for and then it will upload everything to the bucket that we just created website bucket.

One thing that's worth pointing out here you know this is kind of a small example because it needs to fit on a slide but you can take this further and add things like DNS or CDN to really make a nice static site for yourself. So then to actually deploy the site we would say mpx awscdk deploy the website stack and then I'm actually going to pass in my aws profile from the command line so that it knows what environment to deploy to. But the first time that I run this I'm going to see the following error it says this stack uses assets so the toolkit stack must be deployed to the environment. So what that means is I have to bootstrap this environment first and you can see below I've added the mpx awscdk bootstrap and then passed my profile that will create the you know the bootstrapping infrastructure that I spoke about before. Then I can rerun the same deploy and everything should work according to plan this time. So if you want to see what those deployed resources look like in the top left here I have the CloudFormation console that shows the app and the bootstrap stacks. The top right hand corner is the S3 console that's showing the app and bootstraps buckets. Bottom left is the app bucket containing the static assets and the bottom right is the site actually deployed and running in production. Like I said, if you wanted to make this a little fancier you could do something like add DNS in the CDN so you could have a more user-friendly URL there. And then to clean up you'll use the CDK destroy website stack. I also recommend that you go into the web console for AWS and look around S3 and CloudFormation to see that all the resources are cleaned up. I've linked to a CDK issue below where bootstrapping does not always clean up after itself. I wanted to provide you with commands here that you can use to clean up. Or just click through the web console and you should be able to do the same cleanup by hand. And then I wanted to wrap up by talking about the CLI. These are all basically the commands that we used to do the deployment.

8. Installing CDK and Additional Resources

Short description:

You can install the CDK locally or globally, but it is recommended to add it to your package JSON and call it from an NPM script. Other useful commands include CDK-LS, Diff, Metadata, and CDK context. Additional resources include official documentation, CDK source code, and community-created learning materials. The CDK is gaining popularity and removes barriers for JavaScript developers to handle the entire stack. Thank you for attending the talk.

You can install the CDK locally. If you do that, then it becomes known as CDK and not AWS CDK. So that's one thing to note. You can also install it globally with the dash G flag, but I don't really recommend it. Global dependencies are usually not the best thing. So I recommend adding it to your package JSON and calling it from one of your NPM scripts.

So there are also a handful of other commands here that I didn't touch on. CDK-LS will list the stacks that are in the application. Diff will compare the stack with the deployed version or local CloudFormation template. Metadata can display metadata that has been attached to a stack. Similarly, you can pass in key-value pairs called a run-time context to your application using CDK context. There's a doctor command which can look at your project and kind of link it for potential problems. And then CDK-doc can just be used to open up the official documentation in the browser. It's kind of a nice shortcut.

And then finally, I wanted to include some additional resources here. So the first link is the official documentation, the second link is the CDK source code, and then the remaining links are a combination of AWS and community created resources for learning the CDK and providing reference examples. So it can really get you started and up and running pretty quickly. And that's all I had. Thank you again for coming to my talk and have a nice day everyone.

Colin, welcome. Welcome to your Q&A here. First of all, let's have a look at the poll. We asked the folks, you asked the folks, have you used the AWS Cloud Development Kit? And most people said no. Well, why do you think that? I would like to hear your comment on this. It's really not surprising at all. It's, like I said, fairly new. It just went, I guess, production-ready a couple of years ago. I think it's actually starting to catch on though, so I'm hoping to spread the good word of the CDK and hopefully some JavaScript developers out there get a chance to give it a try, take it for a test run. I feel like it really does just knock down one of the last barriers that's there for JavaScript developers to be able to do the entire stack themselves. Exactly, exactly.

9. Benefits of CDK and Comparison to Other Frameworks

Short description:

CDK simplifies infrastructure as code and offers a more compact and familiar syntax compared to CloudFormation. It allows for quick and concise code for tasks that would require many lines in CloudFormation. The CDK can handle rollbacks, but it's unclear if it supports custom conditions. When deploying through a CI/CD pipeline, it is possible to trigger a rollback on the CloudFormation side. In comparison to other frameworks like the serverless framework, the CDK is a first-class citizen in AWS.

And I still remember the day when I saw the first email about CDK within the company. Somebody just emailed, hey, I have this great idea, how about doing this? Wonderful thing. So I do think that the growth of usage of CDK on AWS will grow in time because it just makes things so simple.

One of the points you made in your talk was that it takes a lot of the effort from writing a declarative infrastructure as code to a more sensible, defaulty way of writing infrastructure as code. So what makes you use CDK over CloudFormation, for example? So CloudFormation, to me, it's great because it gives you the ability to deploy and it handles updates and everything like that. It's just a lot of text to manage and sweat through, and it's just very error-prone. To me, the CDK was nice because I'm writing JavaScript, which I'm already doing as I'm application. If there's a syntax error in there, it's a familiar syntax error instead of trying to dig through a large YAML or JSON file. It's so much more compact. On my one side, I showed on the right-hand side, it was like the entire CloudFormation text, and you couldn't read it at all compared to a dozen lines of CDK JavaScript. To me, that's a big win.

I agree. Sometimes, if you want to do something really quick, like create a VPC, on CDK, it's a single line of code. On CloudFormation, it's 87 lines of code.

Let's get to some of the questions we have from the audience. A question from Lara. Is it possible to use the Cloud Development Kit to automate rollbacks based on custom conditions? For example, failed smoke tests or something like that. That's a good question. I don't know that one off the top of my head. It does handle rollbacks, but I don't know that it handles it based on custom conditions or not. That's something I would have to imagine itself. So, let me try to kind of answer this question from my experience. If you are deploying your Cloud Development Kit through a proper CI CD pipeline, you absolutely can fail it. If something happens, you can just trigger a fail rollback on the CloudFormation side, because as Colin says, CDK just uses CloudFormation for a lot of its parts. So, in essence, yeah.

Okay. Question. And these are very common questions that I hear as well when talking about this is, a question from Marc. Are there any benefits in using the Cloud Development Kit over the serverless framework or the serverless.com framework? So, I think there are tradeoffs, as with everything. So, with the CDK, it's a first-class citizen in AWS.

QnA

Benefits of CDK and Transition from CloudFormation

Short description:

The CDK has the ability to use a native programming language to build infrastructure, which makes it easier for JavaScript developers. You can import current resources from CloudFormation into the CDK and gradually transition your infrastructure. The CDK is heavily based on classes to represent objects and their properties, which provides a cleaner code structure.

So, you know, it's built by AWS engineers, supported by AWS engineers. It's guaranteed to work there. The serverless framework, you know, it might work with other clouds a little bit better. But, you know, that's kind of by design. So, I guess, in my opinion, if you're deploying to AWS, using official AWS tools is probably the best-case scenario.

I agree. So, a fair point. You know, serverless framework has its own benefits, especially for serverless applications. You also have SAM on AWS, which is kind of a transformation of CloudFormation. But, CDK, again, like, one of the things that CDK has, and you prove this in your talk, is that it has this ability to use a native programming language to build things out. So, if you're a JavaScript developer, I mean, it's much more easier to write this than try to hash out some JSON or YAML, in this case.

Okay, we have more questions. One coming from AO. For one of us that is already building our infrastructure in CloudFormation, is it possible to import current resources, like a production database or something static, into the Cloud Development Kit? Yes, you should be able to do that. So, I'm working on a somewhat large AWS project right now that's built on top of CloudFormation and you can chip away at it by porting bits of it to the CDK a little bit at a time. So you don't necessarily have to make the whole big bang transition, if that's what you're asking, if that makes sense.

Right, so you're saying that potentially you don't have to transfer your entire thing into CDK at once, you know, you can leave some things and other ways of provisioning things. Right. I'm also definitely not advocating for, you know, if you have a working solution to just completely drop everything and try to re-architect it just because, you'll probably end up with more headaches than times. Yeah, you know, I was one of the things, one of the infinite wisdoms I hear heard out there is the best framework slash programming language is the one you're good at. So that's what that's the one you should use.

Okay, we have a question from SB. Why is CDK so heavily based on classes rather than more usual constructs in JavaScript like functions? So it's just a way of looking at the cloud as a collection of objects that kind of interact together via different properties. So, you know, for example, you have a lambda function, I think it's easy to think of that as a clash, you have an instance of a lambda, it has specific properties on it, like an ARN and things of that nature. Whereas if you were to try to make it more functional, I think the code would be a little less clean in that fashion. Got it. Got it. Okay. Okay. Yeah.

Testing CDK Code and Advice for Novice Users

Short description:

You can test CDK code using Jest and its built-in assertion library. CDK provides helper functions to test specific resources or patterns. Writing unit tests with expectations allows you to catch issues before deploying and debugging in the cloud. Jest's snapshot feature can also be integrated with CDK. For novice CDK users, it's recommended to try out CDK with existing setups or follow tutorials for greenfield development. Take your time, as CDK is straightforward to use.

Like I use my CDK mostly in TypeScript or in Python, but I'm by no means a great developer. I just use it like a utility, so I wouldn't even know how to answer this question. But speaking of programming languages and the ability of CDK to use your generic programming languages, is there a way we can somehow test if we actually deploy things? Because we chatted a bit before in the lightning talks that testing is really important. Can we do the same with CDK code? Is there a way we can test the code before we do?

Yes. So CDK was actually, I don't know if it was an original design goal, but it has been designed such that it integrates really well with Jest and kind of has its own assertion library built into it. So I think I referenced it in my slides. But so basically you can take a CDK stack and you can say expect stack to, and then there are some helper functions. So include a specific resource or include this set of resources or match this pattern. So there's all types of useful utility functions that you can then unit test your stack with before you even go about trying to deploy it and then trying to debug it in the cloud. The more you can do locally, the better.

Yeah. So basically writing your unit test for CDK and have set expecting expectations. I remember once a long time ago, I've done the same thing with Jest. And Jest is this just framework for testing. I've used, instead of doing assertions, I actually use the snapshot feature. So you can also make like snapshots of the thing you want to happen, and if anything changes, it just doesn't work. Excellent. I think CDK also has functions to integrate with snapshots. You can say like the snapshot should mean something. Okay. Excellent. There you go.

Last question for you. We have 71% of people here answering that have not tried CDK or do not use CDK. What is your advice to novice CDK users? So for somebody who just after your talk goes ahead, you know what? I'm going to do something in CDK. What is your advice to them? My advice to them would be, you know, if you have an existing setup already, you can just try out little bits of the CDK and see if it's matching what's already there. If you're lucky enough to be doing greenfield development, then there's lots of tutorials out there and whatnot. You can go through those and make sure that you're basically getting it right the first time. But just take your time. It's actually really straightforward.

Understanding Programming and AWS

Short description:

Understanding the programming language and the desired AWS infrastructure reduces friction. It's helpful to have a background understanding of AWS services like Lambda functions and EC2 instances. Thank you, Colin, for the insightful talk and answering questions. Your time and talk were greatly appreciated.

As long as you understand the language that you're programming in and understand what you're trying to build on AWS, then I think you should find that the friction is pretty low. If you're not entirely sure what you want to build on AWS first, I think it would be helpful to get that background understanding so you understand what a Lambda function is or what type of EC2 instance you want. Something like that.

Yeah. Excellent. Thank you very much, Colin. I appreciate all the questions, all the answers to the questions, and everybody, I appreciate your questions. Thank you very much for your talk. It was amazing, and thank you very much for your time. Thanks.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Native ESM support for Node.js was a chance for the Node.js project to release official support for enhancing the module loading experience, to enable use cases such as on the fly transpilation, module stubbing, support for loading modules from HTTP, and monitoring.
While CommonJS has support for all this, it was never officially supported and was done by hacking into the Node.js runtime code. ESM has fixed all this. We will look at the architecture of ESM loading in Node.js, and discuss the loader API that supports enhancing it. We will also look into advanced features such as loader chaining and off thread execution.
JSNation Live 2021JSNation Live 2021
19 min
Multithreaded Logging with Pino
Top Content
Almost every developer thinks that adding one more log line would not decrease the performance of their server... until logging becomes the biggest bottleneck for their systems! We created one of the fastest JSON loggers for Node.js: pino. One of our key decisions was to remove all "transport" to another process (or infrastructure): it reduced both CPU and memory consumption, removing any bottleneck from logging. However, this created friction and lowered the developer experience of using Pino and in-process transports is the most asked feature our user.In the upcoming version 7, we will solve this problem and increase throughput at the same time: we are introducing pino.transport() to start a worker thread that you can use to transfer your logs safely to other destinations, without sacrificing neither performance nor the developer experience.

Workshops on related topic

Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
WorkshopFree
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
React Summit 2022React Summit 2022
164 min
GraphQL - From Zero to Hero in 3 hours
Workshop
How to build a fullstack GraphQL application (Postgres + NestJs + React) in the shortest time possible.
All beginnings are hard. Even harder than choosing the technology is often developing a suitable architecture. Especially when it comes to GraphQL.
In this workshop, you will get a variety of best practices that you would normally have to work through over a number of projects - all in just three hours.
If you've always wanted to participate in a hackathon to get something up and running in the shortest amount of time - then take an active part in this workshop, and participate in the thought processes of the trainer.
TestJS Summit 2023TestJS Summit 2023
78 min
Mastering Node.js Test Runner
Workshop
Node.js test runner is modern, fast, and doesn't require additional libraries, but understanding and using it well can be tricky. You will learn how to use Node.js test runner to its full potential. We'll show you how it compares to other tools, how to set it up, and how to run your tests effectively. During the workshop, we'll do exercises to help you get comfortable with filtering, using native assertions, running tests in parallel, using CLI, and more. We'll also talk about working with TypeScript, making custom reports, and code coverage.