Part 2 — My Basic Guide for setting up AWS SAM (nodejs + Lambda + API Gateway)

June Ligan
6 min readJun 17, 2022

My goal with this rough documentation is to help my future self and those newbies out there like me that who wants to try out new things, especially this trending Serverless lightweight API in AWS using dynamodb(nosql).

NOTE: this is the 2nd part because I cannot upload an image anymore for our documentation purposes. 😅

Photo by Valeriia Miller from Pexels

Part 1 Link

Let’s get started

  1. ) Access the deployed sam basic app endpoint
    — from the previous doc, we’ve deployed the basic app which gives us the aws endpoint
    — you can also get your deployed endpoint in your AWS via browser
AWS lambda console
Successfully Accessed endpoint

2.) Local run app — run “sam local start-api -t template.yaml”
— let’s try to locally run the app if we can have the same output with the deployed endpoint
— NOTE: by specifying the template file, you’re relying on the actual files of app instead of the built file which is under “.aws-sam” directory, and for me, this will help us to have a fast pace development since we don’t need to build then run-app; There is also a hot-reload when you append “--skip-pull-image”, so, when you’ve change in the JS file then save, this will automatically rerun the app with the new changes.

Localhost endpoint
Result

We’ve successfully created a basic app, next will tackle the template.yaml file then let’s try some basic examples of it.

3.) Explore template.yaml file

3.1.AWS template required config
3.2.Parameters
— These are the variables who holds the value from your samconfig.toml parameter_overrides which can be accessed throughout the file

3.3. Globals
— The default timeout for your all functions under resources, though I haven’t tested it yet 😅

3.4. Resources
— This is where we put all our Lambda function resource, API Gateway resource and Tables (let’s check this out later)
3.5. Function Resource
— You can set any name for this, but make it sure that it suits with your naming standard of your team.
— “Type” property is the identifier if what type of resource you will create, in this example, since we created a lambda function then will use the one that I know 😆 “AWS::Serverless::Function”
3.6. Code-Uri and Handler
— Code-URI should be instantiated in our case since we are zipping it, other info is in the AWS doc. NOTE: if the CodeUri is not supplied, the entire. working directory will be zipped and uploaded. Click Here for more
— Handler is the “<filename>.<functionName>”

Value reference for Handler property of lambda function

3.7. Events
— This is where our API gateway will be instantiated by giving the “type” property value as “API”. Click Here, For more info
“HelloWorld” is just an arbitrary name, In my case I’ll just update this to “Get” since this is an endpoint with method GET, and in the latter part of this doc, we’ll also create something like CRUD events
3.8. Path and Method
— I think it’s already straight forward, I just want you to take note of this part though 😄

3.9. Outputs
— This is where your output will be instantiated if you have one, in our case we’re just relying on the default generated “ServerlessRestApi” though we can create on our own, later on this doc, we’ll create our own Rest API

CRUD implementation (Create, Read, Update, Delete)

  1. ) Add CRUD functions
    — Let’s just add NEW resource our existing template so that we can differentiate the generated and our own creation, NOTE: we’ll now be using dynamodb for our demo CRUD, ok?? 👍
    a. Template.yaml
part 1
CRUD Template for our Lambda function linked to custom API Gateway Resource

NOTE:
— Policies property is required for our access to table Cart
— RestApiId property is needed when we want to link the lambda function to our custom API, let’s try later without linking the lambda function

Cart Table Resource
AWS console result after deploying our AWS sam template.yaml

1.Scan — can be used to get Items which can be combined with the Filters(#3) but take note, it will be filtered after 100% table
2.Query — useful if you want to get the given “id” (aka Partition/Hash key), Partition key is always required when querying
3.Filters — can be combined with query and scan, you can filter by any attribute that exists in your table
4.TableName
5.IndexName — when the “card_user_index ” is selected, the Partition key will be changed to “userId” instead of “id” since we’ve setup the index to use userId as HashKey
6.Result displayed
7.Tables area

b. New files

NOTE: based from the above template.yaml, the CodeUri points to our “./src/cart” in which this directory will be zipped then uploaded to our s3 bucket as what I’ve should in the previous doc.
a.) app.js — the index files of our lambda function which routes the event API request to the selected JS file

app.js sample code

b.) constants.js — contains constant/common values that will be useful to our JS files (i.e. table name)
c.) CRUD files (create, get, get-all, update, delete)

2. ) AWS console equivalent

a.) API Gateway

1 — That is our custom API which is the Practice Api Service which contains the cart endpoints

2 — The Helloworld API

This is what it looks like after we deployed our app, it will create the /cart containing all the “events” which has a type of “Api”

This is the helloworld Api gateway endpoint

This is what it looks like in the AWS Lambda console which contains the 2 endpoints for our “cart” and “helloworld”

This is it for now, I’ll just add a separate rough doc for the accessing the dynamo db in our JS files and also, we’ll create a separate doc for a sample error I’ve encountered 😅.

Please let me know in the comment if you have something in mind. I’ll try my best to respond 🙇 😸

--

--