Building larger serverless applications can be tricky - creating many lambda functions as well as other resources such as DynamoDB tables, S3 buckets, API Gateways takes quite a lot of time if we were to do it manually from AWS Console. Not to mention other problems such as redeploying the app to a different region, reviewing the infrastructure etc.
AWS Serverless Application Model (AWS SAM for short) simplifies a lot of those issues.
Built with with best practices in mind it allows you to:
Take a look at WTF is AWS SAM in this quick 2 minute lesson
Instructor: [00:00] AWS Serverless Application Model, also known as SAM for short, is an open-source framework for building serverless applications. The idea behind SAM is to allow developers to create their functions, databases, APIs, and connect them together with only a few lines of code.
[00:15] SAM is built on top of AWS CloudFormation, but it's much less robust, meaning that it enables you to build serverless applications much faster, because there's simply less code to write.
[00:25] As an example, in order to create a database in SAM, the only line that you have to add to your template is this one, so AWS::Serverless::SimpleTable. It is going to create a Dynamo table with a bunch of default properties. You don't have to define them. Of course, if you want to, you can define the primaryKey, tableName, tags, and so on.
[00:44] When using the serverless application model, you are definitely going to create some Lambda functions. Here in this sample template, we have a resources section, which is going to create our Hello World function. We can see over here that this is the handler and it's going to be executed with Node.js 12 runtime. This function is going to be triggered whenever there's a GET request to our /hello endpoint.
[01:04] SAM has a command-line interface which allows you to build, deploy, and test your Lambda functions locally without having to leave your terminal or, in my case, my DS code.
[01:14] In order to deploy this simple Lambda function to AWS, I need to run two commands. First, I'll build the project and, secondly, deploy it. Once the application start has been deployed, I'm getting an endpoint which I can use straight away in order to execute my Lambda function.
[01:28] Not only that, I can locally invoke this Lambda function by running SAM local invoke, which is incredibly useful when developing a Lambda function, because you get to call the Lambda function on your own machine instead of having to call it on AWS infrastructure.
[01:41] When developing your application with SAM, it's useful to install the AWS Toolkit in your IDE of choice. For instance, over here, I have installed the AWS Toolkit for Visual Studio Code, which can be used to run the Lambda function locally for my editor, and we can see the result over here. Even better, we can debug our Lambda functions locally.
[01:59] If I create a breakpoint over here and click on Debug Locally, I'm able to stop the local invocation of my Lambda function and, for instance, take a look at the event and the context passing to this function.
[02:08] An event currently is an empty object, and this is the context object. As we can see, all those factors combined make for a very smooth development experience when building serverless applications using AWS SAM.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!