February 25, 2021
This post continues on from part 3 in this series. Feel free to check out the first 3 posts if you want to follow along or, if you're specifically looking to set up Dynamo with a serverless app, then read on.
If you've been following along, so far we've:
- set up a simple Node.js serverless app
- tested our lambda with Postman
- updated our function and checked out our logs in CloudWatch.
The focus of part 4 will be on Dynamo. Right now we can hit our customers endpoint to save a customer but the customer isn't actually being saved anywhere. So our customers don't simply disappear into oblivion, it makes sense to start storing them somewhere. Now, if this were a real application you'd want to evaluate the needs of your service to determine which database was most suitable but, seeing this is just for fun and learning, we'll go with DynamoDB - a NoSQL key-value and document database. It's simple to set up and pretty easy to use.
Creating Our Dynamo Table
Let's start by updating our serverless.yml file to give our function permission to save data to Dynamo. To do this, in the provider block, add the following:
In AWS, permissions are managed through IAM. If you're new to this, I recommend reading the documentation to get a better understanding of this service, along with best practices.
By adding this block of code to our serverless file we are stating that we give our function permission to work with Dynamo or, more specifically in this case, to put items into a db table. We can add multiple actions here but I like to add them as I need them, not dump them all in at the start. As we'll only require the put operation to save our customers, this will suffice for now.
Note that for the resource we are specifically stating which table has permissions to put items into Dynamo:
arn:aws:dynamodb:${self:provider.region}:*:table/customers. If we wanted to give more tables this permission as we build out this app, this would need to be updated. Try to avoid using * if possible, which opens permissions up to any resource. Always limit permissions where you can.The next step is to add a new block to our file: resources. In this block we'll be creating the table where we'll store our customers, give it a name, and define the key schema for the table and indexes. For our customers table, we'll be using the id as our primary key which will be the only required value.
That's all for our serverless file. Now it's time to update our saveCustomers logic.
Updating Our Customer File
To start with, add the following 3 lines to the top of your file:
Requiring the aws-sdk will allow us to access the Dynamo document client so we can run queries against our table/s and uuid will be used to create our customer ids. Be sure to install the uuid package before continuing.
First we're going to add a function,
customerInfo, that will define the properties we want to save for each customer.We take in 2 properties, email and password, and return an object with 4 properties:
- id: a randomly generated id using the uuid package we installed.
- email and password: these both come from the event body when a request to save a customer is fired. NOTE: while we are saving a plain string password for the purposes of simplicity right now, this is not something you should ever do in a real application.
- createdAt: stores the timestamp in which the customer was added to the database table.
Next up is our
insertCustomer function where we'll make the request to add our new customer to our customers table.This is where we will create the parameters that need to be passed to Dynamo's put method. The first property is the name of our table and the second is our customer object that we created in
customerInfo. We pass our params object to put and then call the promise method to manage the asynchronous flow.Finally, we need to make some changes to
saveCustomer function. Below the if block where we do our validations, add the following:We start by calling our
insertCustomer function and pass our customerInfo function as the only argument, which in turn takes in the email and password that we pulled from the event body in the request. Inside our then block, we handle successful responses. Note: the callback here is the one we created in a previous part of this series so just cut and paste that in. Finally, in our catch block we then use our callback to handle the rejected scenarios.Add a New Customer to Your Table
The only thing left to do is to make a request from Postman, log into the AWS console and navigate to the Dynamo service. From there, find your customers table and click on the 'Items' tab. You should see your very first customer in the database.
If you made it this far, nice work! If you're running into errors, never fear, check out your CloudWatch logs and start debugging.
Obviously there's a lot of clean up that needs to be done, and we need to stop storing plain string passwords in the database, but up next we'll make a request from a simple UI and resolve the issues we run into.
...