In the previous post, we added provisioning profile for dynamoDB table where we would store our app data and also configured IAM role permissions that our API would need to talk to the dynamoDB table.
In this part, we will start with creating the first endpoint of our API to add/post a new word to the table.
Install aws-sdk, body-parser and uuid
To work with AWS DynamoDB, we would need aws-sdk
package in our serverless application. We’d also install body-parser
package to parse the json data and uuid
to generate unique ids.
$ npm install --save aws-sdk body-parser uuid
To organize our code better, we’ll keep all our code under src
folder.
app_constants.ts
📂 Create a folder src
under the project’s root folder
📂 Create a folder config
under src
📄 Create a file app_constants.ts
under src/config
folder with below code:
create.ts
📂 Create a folder named modules
under src
folder
📂 Create a subfolder named words
under src/modules
.
📄 Create a file create.ts
under src/modules/words
with below code:👇 (here is the code gist)
Add the API Endpoint in serverless.yml
Next, add the API endpoint to map to the above file we created
In serverless.yml
, add a createWord
function under the functions
property as shown below👇 :
( in serverless.yml )functions:
createWord:
handler: src/modules/words/create.main
events:
- http:
path: words
method: post
cors: true
authorizer: aws_iam
hello:
handler: handler.hello
events:
- http:
method: get
path: hello
👆 We added a new function createWord
.events: — http, method:post
⇒ this means the event to trigger this function is http post
. path: words
⇒ The endpoint would have the path /words
, handler: src/modules/words/create.main
⇒ the request would be handled at the main
function in the create.ts
file (we added above).cors: true
⇒ to support CORS as the frontend would be on a different domain.authorier: aws_iam
⇒ this means the access to the API is restricted as per the IAM permissions of the federated identity that the user has been authorized with. We will see how exactly this would work when we would set up an Identity Pool from AWS Cognito service.
Test/mock data
Add mock data to test the service locally
If you remember, in our create
lambda function, we are setting userId
in the data to dynamoDB’s put call as:
userId: event.requestContext.identity.cognitoIdentityId
This would be the federated identity of the user that AWS would set in the request context once the user has authenticated. Right now we don’t have User Authentication set for our serverless application, so at present our lambda function would fail here if we invoke it from the deployed endpoint on AWS.
However, we can give a mock data with userID set to some mock value for testing our function locally using serverless’ invoke local
command.
To set our mock data:
📂 create a folder named mocks
under project’s root folder
📂 create subfolder named words
under mocks
folder (<<rootFolder>>/mocks/words
).
📄 Create a file named create.json
under mocks/words
with below data 👇:
Now that we are ready with the mock data, let’s test our lambda function
$ serverless invoke local --function createWord --path mocks/words/create.json --stage dev
After the command completes successfully, go to your AWS console and select dynamoDB
from the serverless
. On DynamoDB, select ‘vocabWords-dev’ table and check the ‘items’ tab of the table. Here you should see the above crated successfully. 👇
👏 Yay! Our lambda function is working.
In the next post, we will set up an endpoint for reading (GET) words from our DynamoDB words table.
← Prev: provisioning DynamoDB
┈ 🏠 ┈ Next: endpoint to get data