How to build an API endpoint with Node.js, AWS Lambda and AWS RDS PostgreSQL DB [Part 3]
Intro
The new hype around serverless computing (SC) aka Function-as-a-Service (FaaS) made me curious. So I gave it a try to check it out. Therefore I implemented a basic CRUD application for item entities.
In the previous parts, we created the Node.js API application in our local environment. But now it is time to ship our app into the world. Therefore we will finally deploy it as an AWS lambda function and spin up an AWS RDS PostgreSQL DB. Once again, you should be registered at Amazon’s AWS.
I assume you completed the part 1 and part 2 or you have already built an existing Node.js application.
Initialization of the AWS RDS PostgreSQL
You should first create an AWS RDS PostgreSQL instance at AWS. For further details please visit the AWS documentation. Do not forget to use the free tier option and leave all the default options. I created a database called awsdb with a user root and the password password. To test your connection with the AWS DB, you can replace the credentials and host URL from our local development configuration in the …/server/config/config.js file. But before using the API application, run again sequelize db:migrate.
Notice that this is still in the development stage. The given AWS RDS instance is not running anymore, so please set up and connect to your own.
Now that the database is running and the connection is established, we can deploy our application as an AWS lambda function.
AWS lambda deployment
We will use the claudia.js framework for easy deployment. Specifically, we can use the aws-serverless-express module of claudia.js to translate the express.js requests to AWS API Gateway requests. The wrapper function will be generated automatically by a claudia command. Hence, I assume that you already got claudia.js installed.
First, we make some changes in our API entry file app.js and stop listening to the TCP port. Instead, we have to export the module by adding module.exports = app;.
After that, we are ready to wrap our application and create a serverless proxy with the claudia command line interface: claudia generate-serverless-express-proxy --express-module app. If your main Node.js/express application file is called other than app, replace that name. This command will add the aws-serverless-express dependency and add a file (module) called lambda.js.
Now we can finally deploy our application as an AWS lambda function. Again use a claudia command: claudia create --handler lambda.handler --deploy-proxy-api --region eu-central-1. You can set the handler which consists of the currently created lambda module (default name) and an AWS region. The app will now be sent to AWS lambda. You will see the URL in the console. For further details, e.g. how to set limitations for the AWS lambda function, refer to the claudia documentation.
If you change the code of your application and you want to re-deploy it, then use the claudia update command.
Final Test
That’s it! Your API application is finally deployed 🚀
You can once again test the endpoints by using e.g. the postman tool. Notice to use the right URL.
If it should not work and you get a response like internal server error, you might have to change the security group configuration of your AWS RDS instance. Edit the inbound rules and set the source to Anywhere, so that every IP can reach your AWS RDS instance. This is due to the fact that the IP addresses of AWS lambda functions are dynamically created and not known beforehand. More to limitations on AWS lambda function in the Outro section.
Outro
This was just a basic API application. Do not refer to this as best practice in developing an API. The goal was to test how tools like express, sequelize, and claudia can be used for a fast Node.js API deployment in the AWS ecosystem. The advantage of claudia really kicks in, as you can simply build your normal Node.js/express API app. Then, with a few commands, you are able to deploy it as an AWS lambda function.
There are already good articles out there which summarize the pros and cons of AWS lambda functions, as well as the dos and dont’s. One aspect of their limitations is cold starts. Especially if you have to use a virtual private cloud (VPC), the latency of a cold start can add up to 10 seconds. There is a great read about this by Nathan Malishev.
If you want to go fully serverless and exhaust the free tiers of AWS, you should use AWS DynamoDB. The NoSQL DB can also be directly requested via the AWS API Gateway by the client (e.g. web browser). For more information take a look here.
So let’s see if the adaption of serverless functions and services will further increase, and microservices will become nanoservices, and docker becomes obsolete 😱
Thank you for reading my series and I hope I could help you! Feedback is appreciated, just comment below 😊
